Salesforce Governor Limits
What is Salesforce Governor Limits?
What are governor limits in salesforce?
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.
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 cheat sheet.
Here is list of important governor limits in salesforce
- Total number of SOQL queries issued: 100
- Total number of SOSL queries issued : 20
- Total number of DML statements issued : 150
- Total number of records retrieved by SOQL queries : 50,000
- Total number of records processed as a result of DML statements : 10,000
Here is full list of governor limits in salesforce
| Description | Synchronous Limit | Asynchronous Limit |
|---|---|---|
| Total number of SOQL queries issued | 100 | 200 |
| Total number of records retrieved by SOQL queries | 50,000 | 50,000 |
| Total number of records retrieved by Database.getQueryLocator | 10,000 | 10,000 |
| Total number of SOSL queries issued | 20 | 20 |
| Total number of records retrieved by a single SOSL query | 2,000 | 2,000 |
| Total number of DML statements issued | 150 | 150 |
| Total number of records processed as a result of DML statements, Approval.process, or database.emptyRecycleBin | 10,000 | 10,000 |
| Total stack depth for any Apex invocation that recursively fires triggers due to insert, update, or delete statements | 16 | 16 |
| Total number of callouts (HTTP requests or Web services calls) in a transaction | 100 | 100 |
| Maximum cumulative timeout for all callouts (HTTP requests or Web services calls) in a transaction | 120 seconds | 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 | 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 | 10 minutes |
| Maximum number of push notification method calls allowed per Apex transaction | 10 | 10 |
| Maximum number of push notifications that can be sent in each push notification method call | 2,000 | 2,000 |
| Maximum number of EventBus.publish calls for platform events configured to publish immediately | 150 | 150 |
Per-Transaction Certified Managed Package Limits
Certified managed packages—managed packages that have passed the security review for AppExchange—get their own set of limits for most per-transaction limits. Salesforce ISV Partners develop certified managed packages, which are installed in your org from AppExchange and have unique namespaces.
There’s no limit on the number of certified namespaces that can be invoked in a single transaction. However, the number of operations that can be performed in each namespace must not exceed the per-transaction limits. There’s also a limit on the cumulative number of operations that can be made across namespaces in a transaction. This cumulative limit is 11 times the per-namespace limit. For example, if the per-namespace limit for SOQL queries is 100, a single transaction can perform up to 1,100 SOQL queries. In this case, the cumulative limit is 11 times the per-namespace limit of 100. These queries can be performed across an unlimited number of namespaces, as long as any one namespace doesn’t have more than 100 queries. The cumulative limit doesn’t affect limits that are shared across all namespaces, such as the limit on maximum CPU time.
This table lists the cumulative cross-namespace limits.
| Description | Cumulative Cross-Namespace Limit |
|---|---|
| Total number of SOQL queries issued | 1,100 |
| Total number of records retrieved by Database.getQueryLocator | 110,000 |
| Total number of SOSL queries issued | 220 |
| Total number of DML statements issued | 1,650 |
| Total number of callouts (HTTP requests or web services calls) in a transaction | 1,100 |
| Total number of sendEmail methods allowed | 110 |
Lightning Platform Apex Limits
These limits aren’t specific to an Apex transaction; Lightning Platform enforces these limits.
| Description | Cumulative Cross-Namespace Limit |
|---|---|
| The maximum number of asynchronous Apex method executions (batch Apex, future methods, Queueable Apex, and scheduled Apex) per a 24-hour period | 250,000 or the number of user licenses in your org multiplied by 200, whichever is greater |
| Number of synchronous concurrent transactions for long-running transactions that last longer than 5 seconds for each org. | 10 |
| Maximum number of Apex classes scheduled concurrently | 100. In Developer Edition orgs, the limit is 5. |
| Maximum number of batch Apex jobs in the Apex flex queue that are in Holding status | 100 |
| Maximum number of batch Apex jobs queued or active concurrently | 5 |
| Maximum number of batch Apex job start method concurrent executions | 1 |
| Maximum number of batch jobs that can be submitted in a running test | 5 |
| Maximum number of test classes that can be queued per 24-hour period (production orgs other than Developer Edition) | The greater of 500 or 10 multiplied by the number of test classes in the org |
| Maximum number of test classes that can be queued per 24-hour period (sandbox and Developer Edition orgs) | The greater of 500 or 20 multiplied by the number of test classes in the org |
Static Apex Limits
These Apex Limits that are applied across all transactions.
Size-Specific Apex Limits
These Apex Limits related to the size of code.
Miscellaneous Apex Limit
Some more limits that are not covered above.
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
2 comments
Hi,
Many Thanx for sharing the important content.
I have a question regarding the governor limits of Total number of SOQL queries issued?
is it 200 or 100? As i can see the post shows two different answers, one on the “Here is list of important governor limits in salesforce” saying 200 and the other on the “Here is full list of governor limits in salesforce” saying 100
As per my understanding, it is 100. Please let me know if that’s correct or wrong?
Author
In Synchronous Apex request, the number of SOQL queries allowed is 100, In Asynchronous limit is 200.