Salesforce CRM is utilized by an assortment of businesses of all sizes and in different industries. Salesforce has been involved in the effective administration of client data for more than two decades. It has several revolutionary concepts and practices, as well as the ability to access your data anywhere and anytime. This platform has a large number of servers throughout the world, and the organization where you work would also be one of them. These servers have massive databases and machines, and they are so powerful that each server can host many Salesforce instances from different corporations.
Salesforce Developers offer a variety of services to their customers that are precisely tailored as per their requirements. They help in the design, development, and customization of a variety of Salesforce products, platforms, and apps to meet the demands of their clients. But there always exist rules wherever there are finite resources and Salesforce is not an exception.
Salesforce development and operations are not without constraints and regulations. Salesforce developers must adhere to several guidelines while making significant modifications to the system when using the Salesforce CRM platform. And most of these rules and regulations include Salesforce Governor Limits.
What is Multitenant Architecture?
To understand the Governor limits in Salesforce and how they limit Salesforce developers’ operations, it is first crucial to understand the concept of a multitenant architecture. Multitenancy refers to the method of software operation in which multiple independent instances of one or more programs share a common environment.
Multitenant architecture in more simple words is when a single software platform (or any platform in general) is used by several users. Because all the operators use the same version and design of the platform, therefore the Salesforce CRM falls under the category of multitenant architecture.
Here is an example to help you understand:
Consider Salesforce multitenancy simply like renting an apartment in a building. Electricity, gas, and wi-fi bandwidth are all shared resources for every building in the apartment.
Now if numerous flats start plugging in heavy-duty appliances capable of consuming all the electricity. Think what would happen if other flats began downloading large files from the internet.
Even if you paid a premium, it would be challenging to live in a flat where you could not receive proper electricity or reliable Wi-Fi bandwidth.
Here the flats are separate Salesforce organizations, and the apartment complex is a Salesforce server. And this distribution of shared resources is multi-tenancy architecture.
There is one more term used i.e., Single-tenant platforms, and the difference between the single and multi-tenant platforms is that the single-tenant requires users to upgrade it regularly.
Multitenant platforms, on the other hand, upgrade themselves regularly and spread uniform updates to all their users. When it comes to Salesforce, it is a cloud-based CRM, so users do not have to worry about maintaining the Salesforce Platform’s software and hardware.
Also, read: What is Salesforce Health Cloud? Its features & Benefits
What are the Salesforce Governor Limits?
Salesforce Governor Limits are commonly referred to as Apex Governor Limits because they are related to apex customizations and modifications.
The apex runtime engine enforces these runtime limitations to develop scalable and efficient code and prevent processes from monopolizing shared resources.
Governor limits in Salesforce are a vital set of rules that made Salesforce the world’s most popular and authorized customer relationship management (CRM) platform.
Salesforce Governor Limits, to put it in simple terms, are usage caps imposed by Salesforce to ensure efficient processing. This allows multiple users to access the platform at the same time without slowing it down.
This is critical since each programming environment has its own set of structures, capabilities, and limitations. All the platform’s programs, services, and applications run in a multi-tenant environment, which means that their resources, such as memory, network, and database connections, are shared with every other program on the platform. As a result, the platform must guard against rouge, and apps overwhelming system resources.
Every developer must ensure that their code is properly scalable and does not violate the limits. So, it is crucial to follow regulations to prevent developers from wasting resources.
If any of the Salesforce Governor Limits are exceeded or are not met, an error will be generated, and users will be notified promptly. The user’s program would then be shut down because of this error.
Also, read: What is Salesforce Enterprise Territory Management?
Types of governor limits in Salesforce
Here is a sheet for Salesforce Governor Limits that summarises the most important limits that everyone should be aware of:
| Overview | Governor Limit |
|---|---|
| The total number of SOSL queries issued in Salesforce | 20 |
| DML Governor Limits in Salesforce (Total number of statements issued per transaction) | 150 |
| Total number of records retrieved by a single SOSL query | 2000 |
| Total number of records retrieved by SOQL queries | 50000 |
| Total number of records retrieved by Database.getQueryLocator | 10000 |
| Salesforce Governor Limits for heap size total | 6 MB/12 MB |
The following are the Apex Governor Limits in Salesforce:
1) Per-Transaction Apex Limits:
Apex Limits are applied per transaction and are counted for each Apex transaction. These specific limits in the execution method for executing each batch of records will be reset when using Batch Apex.
The restrictions for the synchronous and asynchronous Apex are summarized in the table below:
| Factor | Synchronous Limit | Asynchronous Limit |
|---|---|---|
| Total SOQL queries issued | 100 | 200 |
| Total records retrieved by SOQL queries | 50,000 | |
| Total records retrieved by Database.getQueryLocator | 10,000 | |
| Total SOSL queries issued | 20 | |
| Records retrieved by a single SOSL query | 20,000 | |
| Toal DML statements issued | 150 | |
| Total records processed by DML statements | 10,000 | |
| Stack depth for Apex invocation | 16 | |
| Total callots in a transaction | 100 | |
| Methods allowed per Apex invocation | 50 | 0 in batch & future contexts, 1 in queueable context |
| Number of Apex jobs added | 50 | 1 |
| Toal sendEmail methods allowed | 10 | |
| Total heap size | 6 MB | 12 MB |
| Max. CPU time on Salesforce servers | 10,000 milliseconds | 60,000 milliseconds |
| Execution time for Apex transaction | 10 minutes | |
| Max. push notifications per Apex transaction | 10 | |
| Max push notifications send through each push notification method call | 2000 |
2) Per-Transaction Certified Managed Package Limits
These are the limits that are imposed on managed packages and are different from limits that are applied to the apex that is not part of the managed package.
If a managed package built by a Salesforce ISV has passed a security assessment, the per-transaction limits are often higher.
| Factor | Limit |
|---|---|
| Total SOQL queries issued | 1100 |
| Total retrieved records by Database.getQueryLocator | 110000 |
| Number of SOSL queries issued | 220 |
| Total DML statements issued | 1650 |
| Total Callouts in a transaction | 1100 |
| Toal sendEmail methods allowed | 110 |
For certified managed packages, all transaction restrictions apply individually, except:
- Total heap size
- Maximum CPU time
- Maximum transaction execution time
- Maximum number of unique namespaces
Also, read: Pipedrive vs Salesforce: Which CRM Is Best for Your Business?
3) Lightning Platform Apex Limits
These are the Governor Limits set by the Salesforce Lightning Platform. None of these limits apply to Apex transactions executed by developers.
| Description | Limit |
|---|---|
| The maximum amount of asynchronous method executions per day | 25,000 |
| Parallelly scheduled apex classes | 100 |
| Queued Apex jobs | 5 |
| Max. batches submitted | 5 |
| Parallelly opened query cursors/user | 50 |
| Parallelly opened query cursors/user | 15 |
4) Static Apex Limits
These are the apex governor limits set for the static apex, which apply to different types of queries, callouts, records, loops, and batch sizes, as well as different transactions undertaken by the users.
| Description | Limits |
|---|---|
| The default timeout for transaction callouts | 10 seconds |
| Max. size of callout request or response | 6MB (Synchronous) 12 MB (Asynchronous) |
| SOQL query runtime before cancellation of a transaction | 120 seconds |
| Max. number of class and trigger units of code | 5000 |
| Trigger batch size for Apex | 200 |
| Size of loop list batch | 200 |
| Batch Apex query returned records in Database.QueryLocator | 50 million |
5) Size-Specific Apex Limits
These limits are linked to the size and the number of lines of code on the platform. These are primarily utilized to ensure that no oversized items exist in classes, triggers, or the org.
| Description | Limit |
|---|---|
| The maximum amount of characters/ class | 1 mn |
| The maximum amount of triggers/ class | 1 Million |
| Apex maximum code utilization | 6 MB |
| Limit for method size | 65,535 |
Why are Salesforce Governor Limits enforced?
Salesforce’s platform provides customization in the form of Apex trigger, web services, or declarative changes like flows and process builders. When these customizations run on the platform, they consume limited resources that are shared with other Salesforce instances.
Salesforce makes sure that its platform runs smoothly and that its customers are not disturbed by server failures. As a result, Salesforce Governor Limits were put in place and enforced.
They ensure that any Salesforce instance that shares resources with other instances does not consume all the finite resources and that resources are distributed properly according to the instance subscription model.
Advantages:
- Salesforce’s governor restrictions prohibit other organizations from operating and hence executing lengthy code, which can eat up a lot of memory and even the cloud CPU.
- Apex has an entirely separate set of coding limits.
- These governor limits keep us in the right space of coding when working with Apex.
Also, read: Salesforce Edition Comparison: Features and Applications
How can you avoid hitting these Salesforce Governor Limits?
It is our responsibility to make sure that our code is scalable and does not exceed the governor’s limits. Several tricks and tips can be used to ensure that any customization code is written within these Salesforce Governor Limits. For this you must follow these steps:
- In FOR loop, make sure there are no DML statements or SOQL queries.
- In the loop, avoid using SOQL or DML operations.
- Set Governor Limits, Check the ‘Send Apex Warning Emails’ option on your user record to receive email warnings.
- Bulk up your code and helper methods.
- Large data sets can be queried.
- To avoid apex heap size problems, make sure variables are private or transitory unless they need to be accessible outside the class.
- If we need to process 50,000 records, you should use Batch Apex.
- Streamline the execution of several triggers on a single object.
- For loops, use streamlined queries and collections.
Also, read: Salesforce Customer 360 – All you need to know about
Conclusion
As you can see, there are different kinds of governor limits available in Salesforce, and this is for a good reason: they help us become more efficient administrators and developers. There are several general patterns you can adopt to make sure that you stay within these limits. In general, the most well-known limits in a single transaction revolve around SOQL and DML limits.
Developers will automatically write optimized code that delivers the optimum performance when customizations are done while keeping these limits in mind. Hopefully, you must have now understood that getting past governor limits can be both challenging and enjoyable. If you have any further questions or require help from professionals, feel free to reach us.
Salesforce Consulting Services
If you are new to automation and confused about Workflow or Process Builder. Need not to worry, we have got you all covered. Talk to our experts and clear all the cloudy thoughts about automation.
