Salesforce Architecture - A Deep Dive into the Different Layers of Salesforce

Architecture of Salesforce

By now, you would have understood that you can use Salesforce to deliver a highly customizable application to your customers. In order to understand how Salesforce works, it is important to understand the architecture of Salesforce. In this section of the Salesforce tutorial, you will be learning about the architecture of Salesforce in detail.

Watch this tutorial on Salesforce Architecture:

First, let’s see some important points to get introduced to Salesforce:

• Salesforce is a cloud company, and it offers a trusted and multi-tenant cloud.
• The Salesforce platform is the foundation of Salesforces’ services. It is powered by metadata and is made up of several different parts, such as data services, Artificial Intelligence, and robust APIs for development.
• All apps sit on top of the Salesforce platform. Its pre-built offerings, namely, Salesforce Marketing Cloud and Sales Cloud, along with apps you build using the platform, have consistent, powerful functionality.
• Everything is integrated with Salesforce. The platform technologies such as Salesforce Einstein predictive intelligence and the lightning framework are built according to the user’s convenience.

Think about the Salesforce architecture as a series of layers sitting on top of each other. These layers are illustrated below for better understanding.

Before discussing the Salesforce architecture, let’s first go through the terminology of Salesforce architecture:

• App: All metadata elements such as objects, Visualforce pages, classes, etc. are independent of an app. An app simply helps you cluster things visually. However, internal metadata has nothing to do with the app, but you’ll be able to have a similar tab, VF Page, etc. in multiple apps.
• Instance: An instance of Salesforce is the particular configuration that you see when you log in to Salesforce. A Salesforce instance basically indicates server details for a particular Salesforce organization on which it lives. It is possible for many Salesforce instances to live on one server. While an instance is created based on the location of a user, it will be changed based on the region from where the user logs in.

• Superpod: Superpod is the arrangement of frameworks and stack balancers, including outbound intermediary servers, system and capacity foundations, mail servers, SAN texture, and various other frameworks supporting different instances.

• Org (organization): It is a single consumer of the Salesforce application. Every trial that begins on www.salesforce.com or developer.force.com produces a new org. An org is incredibly adjustable and has very clear security and sharing settings. The UI look and feel, work processes, triggers, custom articles, custom fields on standard salesforce.com CRM questions, and also the custom APIs are very adjustable.
• Sandbox: Whenever a sandbox is created, Salesforce copies the metadata from your production org to the sandbox org. By doing so, you can create multiple copies of your production org in separate environments.

There are four kinds of Salesforce sandbox:

• Developer Sandbox
• Developer Pro
• Partial Copy
• Full Sandbox

Now, let’s move deep into the different layers of the architecture of Salesforce, one by one.

• In Salesforce, all data is stored in a single database schema for all its customers.
• It is economical because resources and maintenance are shared.
• There can be a single instance of a software server with multiple tenants.
• The provider has to update only one application, and the changes will get updated for all clients.

In a multi-tenant architecture, there is one common application serviced to multiple clients. So, in this case, the developer can create a Salesforce Application, upload it onto the cloud, and share it with multiple clients. The major advantage of this multi-tenant architecture is that it becomes cost-effective as the application is shared by multiple clients. The development and maintenance costs of an application can be shared at once. This makes the application very economical per client. Also, if the developer/provider wants to make any update to the provided software, he/she can directly update it in just one place. All clients using the application will get the updated version.
Comparing this with the single-tenant architecture, each client will be having one particular software/application. So in the single-tenant architecture, the development and maintenance cost has to be completely owned by one particular client. Also, if the developer wants to update the application, he/she has to manually update it for each client. Besides, only one application will be able to satisfy one client.

• Salesforce platform uses a metadata-driven development model.
• Developers need to concentrate only on building applications.
• Functionalities of an app are defined as metadata in the database.
• This increases developers’ productivity.

The issues of security get sorted with this particular architecture since here all data is stored on different levels, i.e., data above data. All the data is stored in shared databases; the metadata points to one particular clients’ data in a shared database.

Consider three clients, A, B, and C, sharing a single database. These clients will have access to their own metadata from the shared data. So, each client will have separate metadata. This ensures that you don’t get into someone else’s metadata. This also increases the security of the shared database. Developers just need to create the application and deliver the application to the respective clients’ metadata.

In its list of features, Salesforce includes all aspects of CRM functionality and also provides features for the creation of apps, integrating analytics, and more.

The enterprise ecosystem of Salesforce is huge. There are contributions from a large number of partners by creating and maintaining applications in this platform. This ecosystem is created on top of Salesforce’s unique business model that is focused on engagement and collaboration.

A powerful source of APIs is provided by Salesforce. This APIs help in the development and customization of the Salesforce mobile application. These APIs enable diverse bits of programming to interface with each other and trade data. These APIs are comparable. Without knowing many details, you can connect your apps with other apps.

Salesforce design isn’t just a random series of trial-and-error experiments. Rather, each and every feature of its design has been planned and placed precisely. Once you start working on this architecture, you’ll understand almost all of its functionalities.

In this section of the Salesforce tutorial, we learned about the robust Salesforce architecture. In the next section of this tutorial, we’ll see how we can create a Salesforce Developer account.