Because Apex runs in a multitenant environment, the Apex runtime engine strictly enforces a number of limits to ensure that runaway Apex doesn’t monopolize shared resources. If some Apex code ever exceeds a limit, the associated governor issues a runtime exception that cannot be handled.
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’re different. Otherwise, this table lists only one limit that applies to both synchronous and asynchronous Apex.
|Description||Synchronous Limit||Asynchronous Limit|
|Total number of SOQL queries issued1||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 issued2||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 statements3||16|
|Total number of callouts (HTTP requests or Web services calls) in a transaction||100|
|Maximum 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|
|Maximum number of Apex jobs added to the queue with System.enqueueJob||50|
|Total number of sendEmail methods allowed||10|
|Total heap size4||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 unique namespaces referenced6||10|
|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|
3 Recursive Apex that does not fire any triggers with insert, update, or delete statements exists in a single invocation, with a single stack. Conversely, recursive Apex that fires a trigger spawns the trigger in a new Apex invocation, separate from the invocation of the code that caused it to fire. Because spawning a new invocation of Apex is a more expensive operation than a recursive call in a single invocation, there are tighter restrictions on the stack depth of these types of recursive calls.
5 CPU time is calculated for all executions on the Salesforce application servers occurring in one Apex transaction—for the executing Apex code, and any processes that are called from this code, such as package code and workflows. CPU time is private for a transaction and is isolated from other transactions. Operations that don’t consume application server CPU time aren’t counted toward CPU time. For example, the portion of execution time spent in the database for DML, SOQL, and SOSL isn’t counted, nor is waiting time for Apex callouts.
6 In a single transaction, you can only reference 10 unique namespaces. For example, suppose you have an object that executes a class in a managed package when the object is updated. Then that class updates a second object, which in turn executes a different class in a different package. Even though the second package wasn’t accessed directly by the first, because it occurs in the same transaction, it’s included in the number of namespaces being accessed in a single transaction.
Certified managed packages, that is, managed packages that have passed the security review for AppExchange, get their own set of limits for per-transaction limits with the exception of some limits. Certified managed packages are developed by Salesforce ISV Partners, are installed in your organization from Force.com AppExchange, and have unique namespaces.
Here is an example that illustrates the separate certified managed package limits for DML statements. If you install a certified managed package, all the Apex code in that package gets its own 150 DML statements, in addition to the 150 DML statements your organization’s native code can execute. This means more than 150 DML statements might execute during a single transaction if code from the managed package and your native organization both execute. Similarly, the certified managed package gets its own 100 SOQL queries limit for synchronous Apex, in addition to the organization’s native code limit of 100 SOQL queries, and so on.
These limits count for the entire transaction, regardless of how many certified managed packages are running in the same transaction.
Also, if you install a package from AppExchange that isn’t created by a Salesforce ISV Partner and isn’t certified, the code from that package doesn’t have its own separate governor limit count. Any resources it uses counts against the total for your organization. Cumulative resource messages and warning emails are also generated based on managed package namespaces as well.
For more information on Salesforce ISV Partner packages, see Salesforce Partner Programs.
The limits in this table aren’t specific to an Apex transaction and are enforced by the Force.com platform.
|The maximum number of asynchronous Apex method executions (batch Apex, future methods, Queueable Apex, and scheduled Apex) per a 24-hour period1||or the number of user licenses in your organization multiplied by 200, whichever is greater|
|Number of synchronous concurrent requests for long-running requests that last longer than 5 seconds for each organization.2||10|
|Maximum number of Apex classes scheduled concurrently||100|
|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 concurrently3||5|
|Maximum number of Batch Apex job start method concurrent executions4||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 organizations other than Developer Edition)5||The greater of 500 or 10 multiplied by the number of test classes in the organization|
|Maximum number of test classes that can be queued per 24-hour period (sandbox and Developer Edition organizations)5||The greater of 500 or 20 multiplied by the number of test classes in the organization|
|Maximum number of query cursors open concurrently per user6||50|
|Maximum number of query cursors open concurrently per user 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|
4 Batch jobs that haven’t started yet remain in the queue until they’re started. Note that this limit doesn’t cause any batch job to fail and execute methods of batch Apex jobs still run in parallel if more than one job is running.
5 This limit applies to tests running asynchronously. This includes tests started through the Salesforce user interface including the Developer Console or by inserting ApexTestQueueItem objects using SOAP API.
6 For example, if 50 cursors are open and a client application still logged in as the same user attempts to open a new one, the oldest of the 50 cursors is released. Cursor limits for different Force.com features are tracked separately. For example, you can have 50 Apex query cursors, 15 cursors for the Batch Apex start method, 5 cursors for the Batch Apex execute and finish methods each, and 5 Visualforce cursors open at the same time.
|Default timeout of callouts (HTTP requests or Web services calls) in a transaction||10 seconds|
|Maximum size of callout request or response (HTTP request or Web services call)1||6 MB for synchronous Apex or 12 MB for asynchronous Apex|
|Maximum SOQL query run time before the transaction can be canceled by Salesforce||120 seconds|
|Maximum number of class and trigger code units in a deployment of Apex||5,000|
|For loop list batch size||200|
|Maximum number of records returned for a Batch Apex query in Database.QueryLocator||50 million|
|Maximum number of characters for a class||1 million|
|Maximum number of characters for a trigger||1 million|
|Maximum amount of code used by all Apex code in an organization1||3 MB|
|Method size limit 2||65,535 bytecode instructions in compiled form|
1 This limit does not apply to certified managed packages installed from AppExchange (that is, an app that has been marked AppExchange Certified). The code in those types of packages belong to a namespace unique from the code in your organization. For more information on AppExchange Certified packages, see the Force.com AppExchange online help. This limit also does not apply to any code included in a class defined with the @isTest annotation.
2 Large methods that exceed the allowed limit cause an exception to be thrown during the execution of your code.
|Email Services: Maximum Number of Email Messages Processed
(Includes limit for On-Demand Email-to-Case)
|Number of user licenses multiplied by 1,000, up to a daily maximum of 1,000,000|
|Email Services: Maximum Size of Email Message (Body and Attachments)||10 MB1|
|On-Demand Email-to-Case: Maximum Email Attachment Size||25 MB|
On-Demand Email-to-Case: Maximum Number of Email Messages Processed
(Counts toward limit for Email Services)
|Number of user licenses multiplied by 1,000, up to a daily maximum of 1,000,000|
Using the API or Apex, you can send single emails to a maximum of 1,000 external email addresses per day based on Greenwich Mean Time (GMT). Single emails sent using the Salesforce application don't count toward this limit. There’s no limit on sending individual emails to contacts, leads, person accounts, and users in your organization directly from account, contact, lead, opportunity, case, campaign, or custom object pages.
|Edition||External Address Limit per Mass Email|
|Personal, Contact Manager, and Group Editions||Mass email not available|
|Unlimited and Performance Edition||1,000|
|Maximum number of push notifications allowed for||Limit|
|Mobile applications provided by Salesforce (for example, Salesforce1)||50,000 notifications per app per day|
|Mobile applications developed by your organization for internal employee usage||35,000 notifications per app per day|
|Mobile applications installed from the AppExchange||5,000 notifications per app per day|
Only deliverable notifications count toward this limit. For example, consider the scenario where a notification is sent to 1,000 employees in your company, but 100 employees haven’t installed the mobile application yet. Only the notifications sent to the 900 employees who have installed the mobile application count toward this limit.
Each test push notification that is generated through the Test Push Notification page is limited to a single recipient. Test push notifications count toward an application’s daily push notification limit.