Governor Limits in Salesforce (Updated for 2024)
Many of you are likely aware that Salesforce operates within a multitenant environment, accommodating numerous organizations and users globally. Similar to any infrastructure, its resources are not limitless. Governor Limits in Salesforce are enforced to ensure fair usage and maintain performance, preventing any single organization or user from monopolizing shared resources.
It’s quite common to encounter challenges in effectively distributing and utilizing resources. Hence, to address this issue of scarcity, the platform has implemented governor limits. These limits ensure that Salesforce servers are not excessively utilized and resources are fairly distributed among users.
In this guide, we’ll outline the current governor limits within Salesforce and provide actionable insights on ensuring compliance. For individuals seeking to enhance their understanding of Salesforce’s functionalities, particularly in optimizing development workflows, an exploration of scratch orgs is highly beneficial.
What constitutes Governor Limits within the Salesforce platform?
In Salesforce, governor limits refer to predefined rules and regulations designed to govern and manage resource utilization within the cloud environment. These limits serve to prevent any single organization utilizing Salesforce servers from monopolizing resources excessively.
Governor limits, also known as limitations, serve to safeguard resources like memory, database operations, record processing, and script statements in Salesforce. They are designed to prevent resource abuse by imposing boundaries on code execution and Apex runtime. Essentially, governor limits ensure that code is crafted efficiently, optimizing resource utilization.
When a governor limit is exceeded or breached, Salesforce displays an error component and halts the process that triggered the error. If you’ve encountered these limits before and they’ve resulted in disruptions within your Salesforce Production Org, you may benefit from an Apex code review and optimization. Reach out to our Salesforce development services to implement the necessary adjustments.
Different Categories of Salesforce Governor Limits
Below are a few crucial Apex governor limits enforced on the Salesforce platform:
- Per-Transaction Apex Limits apply universally to each individual transaction. For Batch Apex scenarios, these constraints are reset with each batch execution.
- Per-Transaction Certified Managed Package Limits refer to restrictions imposed on packages installed in an organization with a namespace. These packages are developed by Salesforce partners and have undergone rigorous security checks on the AppExchange platform to ensure compliance with transaction limits.
- The Lightning Platform imposes constraints on Apex functionality, as these restrictions are implemented by the platform and are not specific to individual Apex transactions.
- Static Apex limits encompass restrictions on various aspects such as loop and Apex trigger sizes, callout dimensions and durations, the number of trigger code units, and more.
- Size-Specific Apex Limits, as indicated by their name, are utilized within classes to govern sizes, ensuring that appropriately sized elements are employed.
In addition to Apex limits, there exist other categories of governor limits known as non-Apex limits.
- Restrictions on inbound email reception.
- Constraints on push notifications delivery.
- Regulations regarding the number of Salesforce API requests allowed per user.
- Boundaries for Chatter REST API utilization.
- Limits on SOAP API invocation.
- Boundaries on API query cursors.
- Parameters governing metadata usage.
- Constraints on SOQL and SOSL queries within Salesforce.
- Boundaries on Visualforce functionality.
Synchronous vs Asynchronous Execution
In the Salesforce course, you’ll learn that Apex code can be executed in two distinct manners: synchronously or asynchronously. When executed synchronously, all code runs sequentially in a single operation. Conversely, in asynchronous execution, certain portions of the process are carried out at a later time, running in the background as separate thread steps.
In an asynchronous scenario, users are not required to wait for the process to complete. Asynchronous execution offers additional advantages such as increased governor limits. It’s important to recognize that Salesforce limits can vary based on these different execution types.
These constraints influence the architecture of Salesforce solutions and dictate coding practices. Should these limits be surpassed, it results in errors disrupting standard code execution. Reach out to our team of Salesforce developers to address these issues and enhance code efficiency to operate within set limits.
Outline of Apex Governor Limits in Salesforce
Let’s begin by examining the essential limits that are crucial for everyone to understand in this concise Salesforce governor limits reference guide.
| Overview | Governor Limit |
|---|---|
| The aggregate count of SOSL queries executed within the Salesforce platform. | 20 |
| DML Governor Limits in Salesforce pertain to the maximum count of Data Manipulation Language (DML) statements allowed per transaction. | 150 |
| The aggregate count of records returned by a solitary SOSL query. | 2000 |
| The aggregate count of records fetched via SOQL queries. | 50000 |
| The cumulative count of records obtained through Database.getQueryLocator. | 10000 |
| Heap size total Salesforce Governor Limits. | 6 MB/12 MB |
Per-Transaction Apex Limits
The constraints delineated in the table below are enforced for each Apex transaction. In instances where the constraints differ based on whether the transaction is synchronous or asynchronous, they are delineated in distinct columns.
| Overview | Governor Limits for Synchronous Transactions | Governor Limits for Asynchronous Transactions |
| Total number of SOQL queries executed. | 100 | 200 |
| The aggregate sum of records obtained through SOQL inquiries. | 50000 | |
| The quantity of records obtained via Database.getQueryLocator. | 10000 | |
| Total number of SOSL queries issued. | 20 | |
| Total number of records retrieved through a single SOSL query. | 2000 | |
| Total number of Data Manipulation Language (DML) statements issued. | 150 | |
| Total number of records processed as a result of DML statements, Approval.process, or database.emptyRecycleBin | 10000 | |
| Stack depth total 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) per transaction | 100 | |
| Maximum cumulative timeout for all callouts (HTTP requests or Web services calls) per 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 in queueable context) |
| Total number of allowed sendEmail methods | 10 | |
| Total heap size | 6 MB | (12 MB) |
| Maximum CPU time on the Salesforce servers | 10,000 milliseconds | (60,000 milliseconds) |
| Maximum execution time per 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 | 2000 |
Limits for Certified Managed Packages Per-Transaction
As previously mentioned, these constraints are enforced on third-party packages obtained from the AppExchange. Certified packages adhere to their own combined cross-namespace limits, which can be reviewed in the table provided below for more information.
| Overview | Governor Limit |
| Total number of SOQL queries executed | 1100 |
| Total number of records retrieved via Database.getQueryLocator | 110000 |
| Total number of SOSL queries issued | 220 |
| Total number of DML statements executed | 1650 |
| Salesforce Governor Limits for callouts (HTTP requests or web services calls) per transaction | 1100 |
| Total number of SendEmail methods permitted | 110 |
Lightning Platform Apex Limits
The governor limits outlined in Salesforce pertain to the predefined thresholds managed by the platform.
| Overview | Governor Limit |
| Maximum limit for asynchronous Apex method executions within a 24-hour window, encompassing Batch Apex Governor Limits, future methods, Queueable Apex, and scheduled Apex. | 250,000 or the number of user licenses in your org multiplied by 200, whichever is greater |
| Limit on the number of synchronous concurrent transactions for prolonged processes exceeding 5 seconds per org. | 10 |
| Maximum threshold for concurrently scheduled Apex classes. | 100 (note that for the Developer Edition, the limit is 5) |
| Maximum count of batch Apex jobs in “Holding” status within the Apex flex queue. | 100 |
| Maximum limit for batch Apex jobs queued or active concurrently. | 5 |
| Maximum number of concurrent executions allowed for the start method of batch Apex jobs. | 1 |
| Maximum count of batch jobs that can be submitted during a running test. | 5 |
| Maximum number of test classes that can be queued within a 24-hour period (excluding 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 for sandbox and Developer Edition orgs. | The greater of 500 or 20 multiplied by the number of test classes in the org |
| Maximum limit for query cursors open concurrently per user. | 50 |
| Maximum number of query cursors open concurrently per user specifically for the Batch Apex start method. | 15 |
| Maximum number of query cursors open concurrently per user for the Batch Apex execute and finish methods. | 5 |
Static Apex Limits
The static Apex limits table compiles additional constraints pertaining to Apex callouts, queries, records, and multi-transaction scenarios.
| Overview | Governor Limit |
| The predefined time limit for callouts (HTTP requests or Web services calls) within a transaction. | 10 sec |
| The maximum allowed size for callout requests or responses (HTTP requests or Web services calls). | 6 MB for synchronous Apex | 12 MB for asynchronous Apex |
| The maximum duration allowed for executing a SOQL query before Salesforce cancels the transaction. | 120 sec |
| The maximum permissible count of class and trigger code units in an Apex deployment. | 120 sec |
| The number of records processed in a single execution of an Apex trigger’s batch. | 5000 |
| The number of elements processed in each iteration of a loop within Apex. | 200 |
| The maximum number of records retrieved in a Batch Apex query using Database.QueryLocator. | 50 000 000 |
Size-Specific Apex Limits
The limitations outlined in the accompanying table impose constraints on various sizes within the Apex code, encompassing both character counts and method dimensions.
| Overview | Governor Limit |
| Maximum character limit for a class. | Limitation on method size |
| Maximum character limit for a trigger. | 1 000 000 |
| Maximum cumulative code usage by all Apex code within an org. | 6 MB |
| Limitation on method size. | 65,535 bytecode instructions in compiled form |
How to Around Salesforce Governor Limits
Consider this scenario: Your code boasts exceptional efficiency, yet there are instances where you encounter obstacles preventing you from executing necessary actions due to imposed limits. This prompts the inquiry into strategies for circumventing governor limits within Salesforce.
In navigating through the constraints, various strategies can be employed, such as leveraging asynchronous processing methods like queueables, time-triggered workflow rules, future methods, and batch processing. Additionally, utilizing Platform events stands out as one of the most effective solutions.
When aiming to handle more than 50,000 records, it’s advisable to leverage Batch Apex, a powerful tool for overcoming Salesforce limits. Additionally, adhering to best practices such as bulkifying code, steering clear of SOQL queries and DML statements within loops, and opting for collections or optimized queries can enhance performance and scalability.
Implementing the aforementioned strategies will enhance the scalability and reusability of your code while ensuring compliance with Salesforce governor limits. Reach out to our team of certified consultants to optimize your application with flexible code that avoids exceeding Salesforce limitations.
Governor Limits in Salesforce: Video Guide
