All You Need to Know About Salesforce Governor Limits
The concept of Salesforce Governor Limits exists because Salesforce and Apex run in a multi-tenant environment.
In this article, I will explain what Governor Limits actually are in Salesforce. I’ll also provide some examples of the different types while highlighting why they are so important within a multi-tenancy set-up.
Salesforce Multi-tenancy => Salesforce architecture is so popular because of its multi-tenancy.
Multitenancy is a means of providing a single application to multiple organizations, such as different companies or departments within a company, from a single hardware-software stack. Because of multitenancy, any developer can develop an application, upload it to the cloud, and easily share it with multiple clients or groups. Multiple users share the same server and applications, making it very cost-effective. In Salesforce, thanks to this multi-tenant architecture, all customer data is stored in a single database.
Salesforce Governor Limits?
In order for the code to run efficiently, Salesforce.com sets certain restrictions. Simply put, Salesforce Governor Limits are usage limits enforced by Salesforce to ensure efficient processing. They enable multiple users of the platform without limiting performance.
Types of Salesforce Governor Limits
- Per-transaction Certified Managed Package Apex Limits
- Static Apex Limits
- Lightning Platform Apex Limits
- Size-specific Apex Limits
- Per-transaction Apex Limits
- Miscellaneous Apex Limit
Don't forget to check out: Learn About the Governor Limits in Salesforce
Per Transaction Certified Managed Package Limits: If a managed package developed by a Salesforce ISV has passed a security review, it is generally granted higher transaction limits.
Overview | Governor Limit |
SOQL queries issued (total number) | 1100 |
Records retrieved by Database.getQueryLocator (total number) | 110000 |
SOSL queries issued (total number) | 220 |
DML statements issued (total number) | 1650 |
Governor Limits in Salesforce for the total number of callouts (HTTP requests or web services calls) per transaction | 1100 |
SendEmail methods allowed (total number) | 110 |
Static Apex Limit: Apex Limits that apply to all transactions.
Overview | Governor Limit |
Default timeout of callouts (HTTP requests or Web services calls) in a transaction | 10 sec. |
Max. size of callout request or response (HTTP request or Web services call) | 6 MB for synchronous Apex | 12 MB for asynchronous Apex |
Max. SOQL query run time prior to transaction cancellation by Salesforce | 120 sec. |
Max. number of class and trigger code units in Apex deployment | 5000 |
Batch size of Apex trigger | 200 |
Batch size for loop list | 200 |
Max. record number returned for a Batch Apex query in Database.QueryLocator | 50000000 |
Per-Transaction Apex Limits: These limits are calculated for each Apex transaction. For Batch Apex, these limits are reset for each execution of a batch of records in the execution method.
Overview | Governor Limits for Synchronous Transactions | Governor Limits for Asynchronous Transactions |
SOQL queries issues(total numbers) | 100 | 200 |
Record retrieved by SOQL queries (total numbers) |
5000 | |
Record retrieved by Database.getQueryLocator (total number) |
10000 | |
SOSL queries issued (total number) | 20 | |
Records retrieved by one SOSL query (total number) | 2000 | |
DML statements issued (total number) | 150 | |
Records processed as a result of DML statements, Approval.process, or database.emptyRecycleBin (total number) | 10000 | |
Stack depth total for any Apex invocation that recursively fires triggers because of insert, update, or delete statements | 16 | |
Callouts (HTTP requests or web services calls) per transaction (total number) | 100 | |
Max. cumulative timeout for all callouts (HTTP requests or Web services calls) per transaction | 120 sec. | |
Max. number of methods with the future annotation allowed per Apex invocation | 50 | 0 in batch and future contexts; 1 in queueable context |
Max. number of Apex jobs added to the queue with System.enqueueJob | 50 | 1 |
Allowed sendEmail methods (total number) | 10 | |
Heap size total | 6MB | 12MB |
Max. CPU time on the Salesforce servers | 10 thousand milliseconds. | 60 thousand milliseconds. |
Max. execution time per Apex transaction | 10 min. | |
Max. number of push notification method calls allowed per Apex transaction | 10 | |
Max. number of push notifications that can be sent in each push notification method call | 2000 |
Lightning Platform Apex Limit: These limits are not specific to the Apex transaction and are enforced by the Lightning platform.
Overview | Governor Limit |
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 the 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 is 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 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 Limit: Apex Limits related to code size.
Check out another amazing blog here: Bypass Salesforce Governor Limits when Working with Files
Overview | Governor Limit |
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 |
Miscellaneous Apex Limit: Inbound Email Limits, Push Notification Limits, Governor Limits for Salesforce API Requests, Chatter REST API Limits, SOAP API Call Limits, API Query Cursor Limits, Metadata Limits, SOQL and SOSL Governor Limits in Salesforce, Visualforce Limits
Advantages of Governor Limits in Salesforce
- Governor limits in Salesforce prevent other organizations from using and thus running lengthy code that can take up a lot of memory and even the entire cloud CPU.
- Apex has completely different or unique coding limits.
- These governor limits help us stay in the right coding space with Apex.
Best Practices to Avoid Governor Limits
- Do not have DML statements or SOQL queries inside a For loop.
- Try not to use DML or SOQL operations in a loop.
- Try to bulkify the code and use Helper Methods.
- Query large datasets.
- If we want to process 50,000 records, use Batch Apex.
- One trigger per object.
- Use query and collection simplifications for loops.
- Use @future Appropriately.
- Avoid hard-coding IDs.
I hope you now understand how governor limits in Apex work and how to avoid them.
Conclusion
We hope you now understand how governor limits work in Apex and how to avoid them. When working on code and managing an organization, it's crucial to be aware of the limitations that Salesforce has.
Responses