Salesforce Governor Limits
What is Salesforce Governor Limits?
Salesforce Governor Limits
Apex runtime engine strictly enforces limits to ensure that runaway Apex code or processes don’t monopolize shared resources.
Why Salesforce has Governor Limits?
Because Apex runs in a multitenant environment, the Apex runtime engine strictly enforces limits to ensure that runaway Apex code or processes don’t monopolize shared resources. If some Apex code exceeds a limit, the associated governor issues a runtime exception that cannot be handled.
Type of Governor Limits
- Per-Transaction Apex Limits
- Per-Transaction Certified Managed Package Limits
- Lightning Platform Apex Limits
- Static Apex Limits
- Size-Specific Apex Limits
- Miscellaneous Apex Limit
In this post we will mainly cover 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.
This table lists limits for synchronous Apex and asynchronous Apex (Batch Apex and future methods) when they are different. Otherwise, this table lists only one limit that applies to both synchronous and asynchronous Apex. This table can be used as salesforce governor limits cheat sheet.
|Description||Synchronous Limit||Asynchronous Limit|
|Total number of SOQL queries issued||100||200|
|Total number of records retrieved by SOQL queries||50,000|
|Total number of records retrieved by Database.getQueryLocator||10,000|
|Total number of SOSL queries issued||20|
|Total number of records retrieved by a single SOSL query||2,000|
|Total number of DML statements issued||150|
|Total number of records processed as a result of DML statements, Approval.process, or database.emptyRecycleBin||10,000|
|Total stack depth for any Apex invocation that recursively fires triggers due to insert, update, or delete statements||16|
|Total number of callouts (HTTP requests or Web services calls) in a transaction||100|
|Maximum cumulative timeout for all callouts (HTTP requests or Web services calls) in a transaction||120 seconds|
|Maximum number of methods with the future annotation allowed per Apex invocation||50|
|Maximum number of Apex jobs added to the queue with System.enqueueJob||50|
|Total number of sendEmail methods allowed||10|
|Total heap size||6 MB||12 MB|
|Maximum CPU time on the Salesforce servers||10,000 milliseconds||60,000 milliseconds|
|Maximum execution time for each Apex transaction||10 minutes|
|Maximum number of push notification method calls allowed per Apex transaction||10|
|Maximum number of push notifications that can be sent in each push notification method call||2,000|
For more details about governor limit, please refer to below link Execution Governors and Limits
Avoiding Governor limits
From a Developer’s perspective, it is important to ensure that our code should be scalable and should not hit the governor limits. Its very important to follow some of best practices so that our code does not hit governor limit. These are some of best practices that we should follow:
- Bulkify your Code
- Avoid SOQL Queries or DML statements inside FOR Loops
- Bulkify your Helper Methods
- Using Collections, Streamlining Queries, and Efficient For Loops
- Streamlining Multiple Triggers on the Same Object
- Querying Large Data Sets
- Use of the Limits Apex Methods to Avoid Hitting Governor Limits
- Use @future Appropriately
- Use batch apex if you are working for more than 50000 records.
- Never make any SOQL, DML operation inside the loop.
For more details, refer this APEX best Practices
For other Salesforce post, please refer this link