Salesforce CRM is undeniably becoming omnipresent due to its versatility; it has to fit in the demands of all types of scales of operations & function for diverse domains across the industry sector.
Salesforce has been winning hearts across all sizes of businesses for more than two decades now.
When businesses think of efficiently managing the customer base, the first name to strike their minds is Salesforce- without any doubt.
Designing, building, and customizing Salesforce according to the need of every size & type of business is possible, making it the most sought-after CRM software.
However, the tasks of designing, building, or customizing this CRM for business are done by Salesforce Developers.
They understand the business needs and then make the salesforce platform, tools, and the application function as per the business needs.
Nonetheless, the tasks which Salesforce Developer perform are linked to some restrictions as well as regulations.
While making some pivotal changes in the system, some essential regulations need to be kept in mind by the Salesforce Developers. These rules are majorly called Governor Limits.
Have you been wondering about Governor Limits?
Do you think you need some basic understanding to go about with the services related to Salesforce?
Well, to answer these and many more pertinent questions, let us quickly dive deep into these concepts explained lucidly here:
- We will first focus on the Multitenant Architecture and understand its relationship with the Salesforce Governor Limits.
- Then we will jump straight to understand what Salesforce Governor Limits is?
- And we would be in a state to talk about Types of Salesforce Governor Limits.
- Then before we conclude the blog, we will talk about the best ways to avoid Salesforce Governor limits and the benefits offered by Governor Limits.
So let us quickly roll out an elaborate concept to understand Multitenant Architecture:
Understanding the concept of Multitenant Architecture?
In the most straightforward words, we can say that when a software platform, or a single software platform, is being used by many or multiple users. It can be termed multitenant architecture.
Such is the case with Salesforce CRM because all the users or operators utilize the same version or the same architecture for the Salesforce platform.
There is another term, single-tenant platforms, and the difference between multitenant platforms and the former is that the latter needs to be upgraded by the users for themselves regularly.
The multitenant platforms send regular updates to their users.
However, when it comes to Salesforce, it is a cloud-based CRM; hence, users do not have to put effort into maintaining the software and hardware of the Salesforce Platform.
And since, Salesforce is a multitenant architecture platform, and the users get the latest versions installed in their systems.
To maintain such a platform, Salesforce has a certain set of rules to restrict monopolistic use of this platform.
What are these rules, how do they work or what are their types, and much more; let us read:
What are the Salesforce Governor Limits?
In simpler terms, to make sure that the platform is not misused by anyone, as there are multiple users on the same server, Salesforce enforces specific caps on the platform’s usage.
Hence, multiple users can use the platform without affecting the overall performance.
There is a list of various types of Salesforce Governor Limits.
Some of these types have soft limits, while others have a combination of programming in Apex Language, known as hard limits.
The soft governor limits can be solved by Salesforce or by specific paid add-ons.
For instance, when the limit is 6 MB of Apex code per org, it is a soft limit, and you can extend it depending on your case with the help of Salesforce Support.
While the other types of limits, you might need awareness on API and data storage limits.
For hard limits, the developer needs to find a way out to get the results as the limits cannot be increased in these cases.
Let us read about all such types of Salesforce Governance:
Types of Salesforce Governor Limits
The types are classified based on various factors, but here we have listed more of them and other related details.
The types of Salesforce Governance are:
Per-Transaction Apex Limits: These limits count for each Apex transaction.
For Batch Apex, these limits are reset for each execution of a batch of records in the execute method.
- Per Transaction Certified Managed Package Limits
- Lightning Platform Apex Limit
- Static Apex Limit
- Size-Specific Apex Limit
- Miscellaneous Apex Limit
Let us talk deeply about these various types of Salesforce governor limits for different security levels and other metrics related to code.
Per-transaction Certified Managed Package Limits
This type is relevant when the AppExchange checks have been cleared for the majority of transaction limits.
ISV partners develop the Certified Managed Package, and installation is done from AppExchange with a unique namespace.
Other details include:
| 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 |
Static Apex Limits
The governor limits by Salesforce have different limits for each Apex description.
The limits included in static apex comprise different types of callouts, loops, queries, batch sizes, and transactions.
The limit details for each type are mentioned below:
| 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 |
Per-transaction Apex Limits
These limitations are designed for counting all Apex transactions.
The limits for both synchronous and asynchronous Apex are mentioned 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 |
Lightning Platform Apex Limits
The lightning platform is responsible for the handling of the following limits:
| 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 |
Size-specific Apex Limits
This type serves the purpose of keeping a check on outsized items in classes.
The limitations for size-specific elements include:
| 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 |
Best Practices to follow to avoid Governor limits
Well, there have to be some practices which you can follow to avoid such limits!?
Yes, of course, our experts have listed some of these for you. Let us have a look at these:
- You can try to bulkify your code and the helper method.
- You can avoid SOQL queries or DML statements in FOR loops.
- You can use Collections, Streamlining Queries, and Efficient for Loops.
- Go with Querying Large Data Sets
- Streamline Multiple Triggers on the Same Object
- Do not use any SOQL, DML operation inside the loop.
- Use Limits Apex Methods to Avoid Hitting Governor Limits
- Use @future Appropriately
- Use batch apex if you are working for more than 50000 records.
Benefits of Salesforce Governance limits
You might wonder why one needs to understand these terms and ways to avoid these limits!
Are there some advantages offered by Salesforce Governor limits?
Well, It has many benefits offered by such limits. These benefits are:
- Save space in the entire cloud CPU or the memory itself, and these limits do not let other organizations use or execute lengthy code.
- Apex has unique and different coding limits considering job security.
- These governor limits help to stay the correct space of coding with Apex.
Overall, You can say that Salesforce Governor limits to aid in writing efficient and scalable codes.
Conclusion
Finally, while writing the code, we can say that it is crucial to consider the limits of Salesforce.
It can simply help you in many ways, and you can eventually come out with efficient codes.
If you still have queries and questions and need some experts to help you, feel free to contact us.
We have a team of developers and experts looking forward to helping you with the right solutions.
