Salesforce Governor Limits Simplified
Consider you are living in a hostel with two other roommates. The hostel management will ensure that you get an equal bed, table & chairs, and other necessary items. There will be certain rules which ensure a room can have a maximum occupancy of 3. The hostel gate should be closed by 11 PM and so on.
In order to govern things, hostel management will appoint a warden who would keep a check on everything to ensure things are operating fairly and smoothly.
Similarly, Salesforce has a multi-tenant architecture so its resources are shared across. Salesforce has to ensure that resources are equally used and not dominated by one tenant. To ensure this Salesforce has governor limits to which every tenant has to adhere.
Please note that some limits are shared across the org irrespective of the package and some limits are applied to the respective packages only.
For Example, the Total number of SOQL queries issued governor limits for a managed package is not counted against other managed package code. However, the CPU time limit is common to all Apex code including all the packages installed in the org.
As of writing below are the governor limits for an Apex transaction :
| 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 | 0 in batch and future contexts; 1 in queueable context |
| Maximum number of Apex jobs added to the queue with System.enqueueJob | 50 | 1 |
| Total number of sendEmail methods allowed | 10 | |
| Total heap size | 6 MB | 12 MB |
| Maximum CPU time on the Salesforce servers5 | 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 | |
| Maximum number of EventBus.publish calls for platform events configured to publish immediately | 150 |
Governor limits are subject to change release to release.
Here is the link for Salesforce Governor limits which includes all the limits categories and their values – https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm
We should always design our solution considering the potential breach of governor limits in near future. It could be that while developing and unit testing things look good and to avoid any sudden surprise in production we must adhere to best practices while designing and implementing solutions 🙂
Thank you for visiting SalesforceBlue.com
If you have any queries feel free to write down a comment below 🙂
Top site ,.. amazaing post ! Just keep the work on !