Most of you probably know that Salesforce is a multitenant environment shared by hundreds of organizations and users worldwide. And just like in any infrastructure, its resources aren’t infinite.
It’s no surprise that some challenges often occur when it comes to distributing and using these resources wisely. So, since they are bounded, the platform established so-called governor limits, making sure the Salesforce servers aren’t overused and are shared fairly.
In this article, we’ll show you the existing governor limits for Salesforce and give a couple of tips on how to comply with them. For those looking to delve deeper into Salesforce's capabilities, especially in creating efficient development environments, exploring the concept of a is invaluable.
Table of Content
What Are Governor Limits in Salesforce?
Giving a definition of Salesforce governor limits, they are sets of rules and regulations that restrict the monopolistic use of the resources on the cloud by this or that organization that utilizes Salesforce servers.
Such limitations (aka governors) prevent the abuse of the resources (such as memory, database, number of processed records and script statements, etc.) by establishing constraints that restrict the implementation of code and Apex runtime. Put simply, when explaining what is the use of governor limits in Salesforce, this also means that the executed code should be written optimally in terms of resource usage. As a result, all parts of the Salesforce environment, including Salesforce Einstein Analytics and others, work efficiently without performance bottlenecks.
When a governor limit is surpassed or violated, Salesforce shows an error and pauses the process that caused the error. If you've already faced these limits and they caused disruptions in the SF Production Org, you might need the APEX code review and optimization. Turn to our to make the changes required. Apart from that, you need to keep in mind certain restrictions like Salesforce developer account limitations. From restrictions on data storage and user accounts to API calls, they can impact how you test and develop within the Salesforce environment and prevent any one developer account from monopolizing server resources.
Types of Salesforce Governor Limits
Here are some Apex governor limits on the Salesforce platform:
- Per-Transaction Apex Limits (such limitations are applicable for every Apex transaction; what’s for Batch Apex cases, limitations are reset);
- Per-Transaction Certified Managed Package Limits (such limits are applied to the packages installed to an org with a namespace, such packages were created by SFDC partners and have successfully passed the majority transaction limit security checks run by the AppExchange);
- Lightning Platform Apex Limits (such limitations are enforced by the platform as they aren’t particular to Apex transactions);
- Static Apex Limits (restricts loop and apex trigger sizes, callout sizes and times, trigger code unit numbers, etc.);
- Size-Specific Apex Limits (as evident from the name, such limits are used to regulate sizes so that no inappropriately sized items are used in all the classes).
There are also other types of governor limits. They're called non-Apex limits:
- 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.
Synchronous vs Asynchronous Execution
An Apex code can be run in two ways: synchronously or asynchronously. With the first, all of the code gets executed at once in a single go. In the second case, part of the process gets executed after some time in the background as a separate thread step.
In such an async scenario, users don’t have the necessity to wait before the process gets finished; other benefits of asynchronous execution include bigger governor limits. Note that based on these execution types, Salesforce limits can also vary.
These limits impact both how you architect SF solutions and the way the code is written. If the limit is exceeded, it causes an error that breaks normal code execution. Contact our to handle the issues and optimize the existing code to perform within limits.
List of Governor Limits in Salesforce for Apex
Major Governor Limits
Firstly, in this small Salesforce governor limits cheat sheet, let’s overview the important limits that everyone should know:
| Overview | Governor Limit |
| Total number of SOSL queries issued in Salesforce | 20 |
| DML Governor Limits in Salesforce (Total number of issued statements per transaction) | 150 |
| Total number of records retrieved by a single SOSL query | 2000 |
| Total number of records that were retrieved by SOQL queries | 50000 |
| Total number of records retrieved by Database.getQueryLocator | 10000 |
| Salesforce Governor Limits for heap size total | 6 MB/12 MB |
Per-Transaction Apex Limits
The limits in the table below are applied for every Apex transaction. In some cases, when the limits vary depending on whether the transaction is synchronous or asynchronous, they are indicated in separate columns.
| Overview | Governor Limits for Synchronous Transactions | Governor Limits for Asynchronous Transactions |
| SOQL queries issued (total number) | 100 | 200 |
| Records retrieved by SOQL queries (total number) | 50000 | |
| Records 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 | 6 MB | 12 MB |
| 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 | |
Per-Transaction Certified Managed Package Limits
As stated earlier, such limits are applied to third-party-developed packages installed from the AppExchange. Certified packages have their own cumulative cross-namespace limits applied; browse details on them in the table below.
| 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 |
Lightning Platform Apex Limits
The following governor limits in Salesforce refer to the limits that are handled by the platform:
| Overview | Governor Limit |
| Max. number of asynchronous Apex method executions (these include Batch Apex Governor Limits in Salesforce, future methods, Queueable Apex, and scheduled Apex) for every 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 (which take more than 5 sec per org.) | 10 |
| Max. number of concurrently scheduled Apex classes | 100 (note that for the Developer Edition, the limit is 5) |
| Max. number of “Holding” status batch Apex jobs in an Apex flex queue | 100 |
| Max. number of batch Apex jobs queued or active concurrently | 5 |
| Max. number of batch Apex job start method concurrent executions | 1 |
| Max. number of batch jobs that can be submitted in a running test | 5 |
| Max. number of test classes that can be queued within 24 hours (not applicable to Developer Edition) | The greater of 500 or 10 multiplied by the number of test classes in the org |
| Max. 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 |
| Max. number of query cursors open concurrently per user | 50 |
| Max. number of query cursors open concurrently per user for the Batch Apex start method | 15 |
| Max. number of query cursors open concurrently per user for the Batch Apex execute and finish methods | 5 |
Static Apex Limits
The following table on static Apex limits collects the extra restrictions regarding Apex callouts, queries, records, and when there’s more than one transaction.
| 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 | 50 000 000 |
Size-Specific Apex Limits
The limits in the following table restrict the sizes indicated within the Apex code, including Apex character limit Salesforce and method size.
| Overview | Governor Limit |
| Max. number of characters for a class | 1 000 000 |
| Max. number of characters for a trigger | 1 000 000 |
| Max. amount of code used by all Apex code in an org | 6 MB |
| Method size limit | 65,535 bytecode instructions in compiled form |
How to Bypass Salesforce Governor Limits
Imagine the following scenario: your code is highly efficient, but you still come across situations when you can’t perform the action that you need due to the limits. This is exactly when the question of how to avoid governor limits in Salesforce arises.
There are several ways of getting around the limits, including via asynchronous processing like queueables, time-based workflow rules, future methods, and batches, as well as by publishing Platform events (the last is stated among the best solutions).
Mentioning other tips for overcoming the limits, if you’re planning to work with over 50k records, it is wise to make use of Batch Apex. Plus, it is considered good practice to bulkify code and avoid SOQL queries and the use of DML statements within a loop (collections or streamlining queries are better choices for this).
The above-stated practices will make your code scalable and reusable without violating SF governor limits. Contact our certified consultants to fix your application with versatile code which doesn't hit the limits imposed by Salesforce.
Get a Free Salesforce Audit Example
Explore our Salesforce audit report on diagnosing common bottlenecks in the Salesforce ecosystem.
Final Thoughts
To conclude, it is vital to keep in mind the limits that Salesforce has when working on your code and managing your org. If you still have some remaining questions on how to handle Salesforce governor limits, you’re more than welcome to turn to us for
