Salesforce Governor Limits
Governor Limits in Salesforce are used to ensure that there is an efficient use of resources present on the multitenant Force.com platform. There are some limits which are specified by Salesforce.com for code execution to have effective processing.
Before moving on, let’s see what we’ll be learning by the end of this tutorial on Governor Limits in Salesforce:
- Salesforce Governor Limits
- What are Governor Limits
- Types of Governor Limits
- Advantages of Governor Limits in Salesforce
- How can you avoid Salesforce Governor Limits?
Visit our Salesforce Community to get answers to all your queries!
What are Governor Limits?
In order to make sure that no one acquires someone else’s resources, Force.com has actually created a set of limits that govern the normal code execution. Salesforce had to do this because of its multitenant architecture, wherein a single resource is shared by all organizations and customers. If any of the Governor Limits are not followed, an error is thrown, and the execution of the program stops or halts. It is hence important to make sure that your code is scalable and doesn’t disobey any Governor Limits. These limits are referred to as a single transaction basis, i.e., a single trigger execution.
Types of Governor Limits in Salesforce
- Per-transaction Certified Managed Package Limits
- Static Apex Limits
- Per-transaction Apex Limits
- Lightning Platform Apex Limits
- Size-specific Apex Limits
Interested in learning Salesforce? Enroll in our Salesforce Training now!
Per-transaction Certified Managed Package Limits
Certified managed packages are those managed packages which have already passed the security review for AppExchange for the most transaction limits. Certified managed packages are developed by Salesforce ISV partners and are installed in your org from AppExchange having unique namespaces.
So, under this Governor Limit, there is no limit for the number of certified namespaces that can be invoked using a single transaction. But, a condition here is that the number of operations which can be performed in a single namespace shouldn’t exceed the per-transaction limits. Also, there is a limit on the collective number of operations that can be made across namespaces in any transaction. The collective limit is 11 times per namespace. The shared limits around all namespaces are not affected by the collective limits, such as that of a limit on maximum CPU time.
|Description||Cumulative Cross-namespace Limits|
|The total number of SOQL queries that are issued||1,100|
|The total number of records that are retrieved by Database.getQueryLocator||110,000|
|The total number of SOSL queries that are issued||220|
|The total number of DML statements that are issued||1,650|
|The total number of callouts (either HTTP requests or Web services calls) in a transaction||1,100|
|The total number of sendEmail methods that are allowed||110|
All transaction limits count individually for certified managed packages expect:
- Maximum CPU time
- Total heap size
- Maximum number of unique namespaces
- Maximum transaction execution time
Each of these limits counts for all transaction, despite the number of certified managed packages which run in the same transaction. If you are installing a package from AppExchange which has been created by an uncertified Salesforce ISV partner, then that particular package’s code won’t have its own individual Governor Limits. Any resources used by the package count against the total Governor Limits for your org. All the collective resource messages and warning emails are also generated according to the respective package namespaces.
Static Apex Limits
By now, you would know that there are various Governor Limits for each and every description we are giving in Apex. So, there are more Governor Limits for Static Apex, i.e., for different kinds of callouts, queries, loops, records, batch sizes, along with different transactions. Let’s look at these limits individually:
|The default timeout of callouts (either HTTP requests or web services calls) in a transaction||10 seconds|
|The maximum size of the callout request or response (either HTTP request or web services call)||6 MB for synchronous Apex or 12 MB for asynchronous Apex|
|The maximum SOQL query runtime before Salesforce cancels the transaction||120 seconds|
|The maximum number of class and trigger code units in the deployment of Apex||5,000|
|Apex trigger batch size||200|
|For loop list batch size||200|
|The maximum number of records that are returned for a Batch Apex query in Database.QueryLocator||50 million|
Per-transaction Apex Limits
The per-transaction Apex Limits are used for counting each Apex transaction. When we talk about Batch Apex, these particular limits are reset for the execution of each batch of records in the execute method. The table below summarizes the limits for the synchronous and asynchronous Apex:
|Description||Synchronous Limits||Asynchronous Limits|
|The total number of SOQL queries that are issued||100||200|
|The total number of records that are retrieved by the SOQL queries||50,000|
|The total number of records that are retrieved by Database.getQueryLocator||10,000|
|The total number of the SOSL queries that are issued||20|
|The total number of records that are retrieved by a single SOSL query||20,000|
|The total number of DML statements that are issued||150|
|The total number of records that are processed as a result of DML statements, Approval.process, or database.emptyRecycleBin||10,000|
|The total stack depth for any Apex invocation that recursively fires triggers with insert, update, or delete statements||16|
|The total number of callouts (either HTTP requests or web services calls) in a transaction||100|
|The maximum cumulative timeout for all callouts (either HTTP requests or web services calls) in a transaction||120 seconds|
|The maximum number of methods with the future annotation that are allowed per Apex invocation||50||0 in batch and future contexts and 1 in the queueable context|
|The maximum number of Apex jobs that are added to the queue with System.enqueueJob||50||1|
|The total number of sendEmail methods that are allowed||10|
|The total heap size||6MB||12MB|
|The maximum CPU time on Salesforce servers||10,000 milliseconds||60,000 milliseconds|
|The maximum execution time for each Apex transaction||10 minutes|
|The maximum number of push notification method calls that are allowed per Apex transaction||10|
|The maximum number of push notifications that can be sent through each push notification method call||2,000|
Lightning Platform Apex Limits
The limits given below aren’t distinct to any Apex transaction and therefore are administered by the Lightning platform.
|The maximum number of asynchronous Apex method executions (Batch Apex, future methods, Queueable Apex, and Scheduled Apex) per 24-hour period||Either 250,000 or the number of user licenses in your org multiplied by 200, whichever is greater|
|The number of synchronous concurrent transactions for long-running transactions, which last longer than 5 seconds for each org.||10|
|The maximum number of Apex classes scheduled concurrently||100. In Developer Edition org, the limit will be 5|
|The maximum number of Batch Apex jobs in the Apex flex queue that is in the Holding status||100|
|The maximum number of Batch Apex jobs that are queued or active concurrently||5|
|The maximum number of Batch Apex job start method concurrent executions||1|
|The maximum number of batch jobs that can be submitted in a running test||5|
|The maximum number of test classes that can be queued in a 24-hour period (in Production org other than Developer Edition)||Either 500 or 10 multiplied by the number of test classes in the org, whichever is greater|
|The maximum number of test classes that can be queued in a 24-hour period (Sandbox and Developer Edition org)||Either 500 or 20 multiplied by the number of test classes in the org, whichever is greater|
|The maximum number of query cursors open concurrently per user||50|
|The maximum number of query cursors open concurrently per user for the Batch Apex start method||15|
|The maximum number of query cursors open concurrently per user for Batch Apex execute and finish methods||5|
Size-specific Apex Limits
The size-specific Apex Limits are specifically for making sure that there are no over-sized elements present in a class, trigger, org, etc.
The following table gives you the limits for each of these:
|The maximum number of characters in a class||1 million|
|The maximum number of characters in a trigger||1 million|
|The maximum amount of code used by all Apex codes in org1||6 MB|
|The method size limit 2||65,535 bytecode instructions in a compiled form|
Advantages of Governor Limits in Salesforce
- Governor Limits in Salesforce prevent other org from using and hence executing lengthy code which in turn takes up a lot of space in the memory, maybe all the cloud CPU.
- Apex has completely different or unique coding limits.
- These Governor Limits help you stay in the right space of coding with Apex.
Interested in learning Salesforce? Check out the Salesforce Training in Bangalore!
How can you avoid Salesforce Governor Limits?
Being a developer, it is necessary for you to make sure that your code is scalable and doesn’t hit any Governor Limits. But how? Go through the following practices which will help you in staying in these Governor Limits in Salesforce:
- Do not have DML statements or SOQL queries inside of your FOR loop
- Try not to use SOQL or DML operations inside a loop
- Try to bulkify your code and your helper methods
- Can query large data sets
- If you are working for 50,000 records, use Batch Apex
- Streamline various triggers on the same object
- Use Streamlining Queries and collections for loops
- In order to avoid hitting Governor Limits, use limits Apex methods
I hope by now, you have understood how Governor Limits in Apex work and how you can avoid them.
Prepare yourself for the industry by going through this Top Salesforce Interview Questions and Answers!