If you’ve been navigating the Salesforce landscape for any length of time, you’ve likely come across the term ‘multi-tenant’. But what does it really mean, and how does it impact the way the Salesforce platform operates? Let’s delve into this key architectural concept.
What is Multi-tenant Architecture?
Multi-tenant architecture is a software architecture principle where a single instance of a software application serves multiple customers, known as ‘tenants’. This architecture isolates and simultaneously supports the varying requirements of many tenants. A tenant can be an organization, a business unit, or even an individual. The best way to understand it in the context of Salesforce is to think of your Salesforce org as a tenant.
The Role of Metadata
Another crucial term to understand in the Salesforce ecosystem is ‘metadata’. Metadata is data that describes various elements in your applications. This could refer to elements of your user interface, automations, objects, fields, etc.
When you create a new object or build an automation in Salesforce, unlike traditional on-premise systems, the platform doesn’t create an actual table in the underlying database or compile any code. Instead, it stores metadata, which it uses to materialize virtual application components dynamically at runtime.
How Salesforce Supports Multi-tenant Architecture
A single instance of the Salesforce platform uses a single, shared multi-tenant database with a shared schema that stores tenant-specific metadata and data. This data and metadata are then virtualized into tenant-specific database schemas.
There’s also a multi-tenant kernel, also referred to as the application runtime. The kernel handles requests from various tenants and sends responses back to them. When the kernel receives a request, it reads the metadata and data from the virtual schemas to dynamically provide tenant-specific applications, business logic, and APIs at runtime.
Understanding the Control you have as an Architect
As an architect working with Salesforce, it’s important to note that the functionality described above is hardwired into the platform. There’s nothing you can do to change it. However, understanding how Salesforce operates under the hood will help you make more informed decisions when it comes to aspects you can control. It also adds clarity to some of the topics discussed in the Well-Architected Framework.
This article only scratches the surface of the concept of multi-tenant architecture in Salesforce. To explore this topic further, check out the Platform Multi-tenant Architecture document available on the Salesforce Architects website, and the Salesforce Well-Architected Framework. Links to these resources can be found below.
Stay tuned for our next article, where we will delve deeper into the data layer of the Salesforce platform’s architecture. Don’t forget to follow us for more insights into the fascinating world of Salesforce.
