When I try to explain multi-tenancy to my customers, I always compare it to an apartment block.
For example, consider a scenario, where you – as a company or a customer – rent an apartment in a block that is owned by Salesforce, who is your landlord:
Here, your apartment has specific layouts and resources – that is, it has a number of rooms divided by walls. In addition to this, it has central heating, electricity, water, and more. To access and use this apartment, you pay a monthly rent, and everything else is taken care of for you and the other occupants in the building by your landlord.
Apart from your apartment (which is your private space), all the other resources are shared by the occupants of the building. This means that if Salesforce decides to upgrade the central heating to underfloor heating, then you will automatically benefit from this. You can see this as three releases (that is, upgrades containing new features and enhancements) a year, which Salesforce implements.
The preceding diagram represents the difference between buying a single house, which is yours (Single-Tenancy), and renting an apartment in a block with multiple apartments (Multi-Tenancy).
Within your apartment, you can design your interior just the way that you want, and adjust it to your needs and personal preference! For instance, you can choose what room to have as your bedroom or your kitchen; or, alternatively, you can use the whole apartment as an office space. You can even paint the walls blue or flashy green if you want to. This is similar to using a Salesforce Platform, where once you have access to your space, you can then create new custom objects, add fields, and automate features to suit your business needs.
The only thing that you can't do is break down the walls – otherwise, the whole building will collapse, right? Even though you have full flexibility in rearranging your apartment, you are still limited when it comes to certain things! For example, you can't put in a 5-meter sofa if the size of the room is smaller than this; additionally, you can't put in a Christmas tree that is higher than the height of your room, or you would need to break the ceiling, and your neighbor would start a lawsuit against you. Alternatively, you can't just install multiple high-voltage accessories or machines in your apartment without the electricity box exploding and leaving the whole building without power!
I use this analogy in order to explain the governor limits that Salesforce enforces. Salesforce enforces these limits to make sure that no one single occupant will consume resources that could impact the other tenants or occupants who are using the Salesforce infrastructure.
Salesforce uses a multi-tenancy architecture, meaning that a number of organizations (orgs) share the same IT resources, as opposed to dedicated resources. This results in a standard environment that is fully operated and managed by Salesforce, which is much more efficient and cost-effective for your company.
The self-contained unit that allows an org to run is called an instance; it contains everything that is needed to run an org:
- An application and database server
- A file server
- A server, storage, and network infrastructure
An org is an independent configuration (or metadata) and data that is dedicated to a customer. It is represented by a unique ID that you can find in the Company Profile section in Setup. You must provide this ID each time you contact Salesforce support for Cases, Feature Request, and more. Each org only runs on one instance, which serves thousands of other orgs.
The org's unique ID is stored in every table in the shared database to allow the filtering of data, and to ensure that a client's data is only accessed by that client alone.
Some advantages of multi-tenancy are as follows:
- All Salesforce customers, from small businesses to enterprise companies, are on the same code base and they all benefit from the same features and new functionality.
- Salesforce upgrades are easy, automatic, and seamless. There are three automatic upgrades a year, which are called the Spring, Summer, and Winter releases.
- With upgrades, a version is associated with every Apex trigger and Apex class. Here, backward compatibility is assured.
- Each class has a version associated with it called the API version. When you move to the next release, the Apex class always uses the older version of the compiler to guarantee this backward compatibility. Otherwise, you can modify the code to work on the newest version.
So, if all resources are shared by multiple customers, how does Salesforce ensure that one customer doesn't eat up all resources or break things that could impact all other customers on the same instance?
Salesforce controls this by enforcing two things, which can be considered as the side effects of multi-tenancy:
- Governor limits: These are the limits enforced by Salesforce that cannot be changed, and they are the same for anyone using the platform. For example, you can only use 100 queries in one execution context or perform 150 DML (short for Data Manipulation Language) statements in one execution context. Don't worry if you don't understand this yet, as we'll come back to this later. You can find the list of all the governor limits in the Salesforce documentation at https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm.
- Mandatory testing: Salesforce forces you to test your code before you are allowed to deploy it to production or upload a package to the AppExchange. At least 75% of all code must be covered by tests and they should all pass. Every trigger within your deployment package needs at least some coverage. It's best practice to test all possible scenarios, including positive and negative tests, in addition to testing for bulk updates or creation.