Apex Developer Guide

Apex Developer Guide
Getting Started with Apex
Writing Apex
Running Apex
Invoking Apex
Apex Transactions and Governor Limits
Apex Transactions
Execution Governors and Limits
Set Up Governor Limit Email Warnings
Running Apex within Governor Execution Limits
Using Salesforce Features with Apex
Integration and Apex Utilities
Debugging, Testing, and Deploying Apex
Apex Language Reference
Appendices
Glossary
PDF

Newer Version Available

This content describes an older version of this product. View Latest

Execution Governors and 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.
The Apex limits, or governors, track and enforce the statistics outlined in the following tables and sections.

In addition to the core Apex governor limits, email limits and push notification limits are also included later in this topic for your convenience.

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’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 cumulative 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 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
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 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
1 In a SOQL query with parent-child relationship subqueries, each parent-child relationship counts as an extra query. These types of queries have a limit of three times the number for top-level queries. The limit for subqueries corresponds to the value that Limits.getLimitAggregateQueries() returns. The row counts from these relationship queries contribute to the row counts of the overall code execution. This limit doesn’t apply to custom metadata types. In a single Apex transaction, custom metadata records can have unlimited SOQL queries. In addition to static SOQL statements, calls to the following methods count against the number of SOQL statements issued in a request.
  • Database.countQuery
  • Database.getQueryLocator
  • Database.query
2 Calls to the following methods count against the number of DML statements issued in a request.
  • Approval.process
  • Database.convertLead
  • Database.emptyRecycleBin
  • Database.rollback
  • Database.setSavePoint
  • delete and Database.delete
  • insert and Database.insert
  • merge and Database.merge
  • undelete and Database.undelete
  • update and Database.update
  • upsert and Database.upsert
  • EventBus.publish
  • System.runAs

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.

4 Email services heap size is 36 MB.

5 CPU time is calculated for all executions on the Salesforce application servers occurring in one Apex transaction. CPU time is calculated for the executing Apex code, and for 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.

  • Limits apply individually to each testMethod.
  • To determine the code execution limits for your code while it is running, use the Limits methods. For example, you can use the getDMLStatements method to determine the number of DML statements that have already been called by your program. Or, you can use the getLimitDMLStatements method to determine the total number of DML statements available to your code.

Note

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. Certified managed packages are developed by Salesforce ISV Partners, are installed in your org from Salesforce 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. These DML statements are in addition to the 150 DML statements your org’s native code can execute. This limit increase means more than 150 DML statements can execute during a single transaction if code from the managed package and your native org both execute. Similarly, the certified managed package gets its own 100-SOQL-query limit for synchronous Apex, in addition to the org’s native code limit of 100 SOQL queries.

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.

These cross-namespace limits apply only to namespaces in certified managed packages. Namespaces in packages that are not certified don’t have their own separate governor limits. The resources they use continue to count against the same governor limits used by your org's custom code.

Note

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
All per-transaction limits count separately for certified managed packages except for:
  • The total heap size
  • The maximum CPU time
  • The maximum transaction execution time
  • The maximum number of unique namespaces

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 limits. Any resources it uses count against the total governor limits for your org. Cumulative resource messages and warning emails are also generated based on managed package namespaces.

For more information on Salesforce ISV Partner packages, see Salesforce Partner Programs.

Lightning Platform Apex Limits

The limits in this table aren’t specific to an Apex transaction and are enforced by the Lightning Platform.

Description Limit
The maximum number of asynchronous Apex method executions (batch Apex, future methods, Queueable Apex, and scheduled Apex) per a 24-hour period1 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.2 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 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 orgs other than Developer Edition)5 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)5 The greater of 500 or 20 multiplied by the number of test classes in the org
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

1 For Batch Apex, method executions include executions of the start, execute, and finish methods. This limit is for your entire org and is shared with all asynchronous Apex: Batch Apex, Queueable Apex, scheduled Apex, and future methods. To check how many asynchronous Apex executions are available, make a request to the REST API limits resource. See List Organization Limits in the REST API Developer Guide. The licenses that count toward this limit are full Salesforce user licenses or App Subscription user licenses. Chatter Free, Chatter customer users, Customer Portal User, and partner portal User licenses aren’t included.

2 If more transactions are started while the 10 long-running transactions are still running, they’re denied.

3 When batch jobs are submitted, they’re held in the flex queue before the system queues them for processing.

4 Batch jobs that haven’t started yet remain in the queue until they’re started. If more than one job is running, this limit doesn’t cause any batch job to fail and execute methods of batch Apex jobs still run in parallel.

5 This limit applies to tests running asynchronously. This group of tests 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 Lightning Platform features are tracked separately. For example, you can have 50 Apex query cursors, 15 cursors for the Batch Apex start method, 5 cursors each for the Batch Apex execute and finish methods, and 5 Visualforce cursors open at the same time.

Static Apex Limits

Description Limit
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 Salesforce cancels the transaction 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

1 The HTTP request and response sizes count towards the total heap size.

Size-Specific Apex Limits

Description Limit
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 org1 6 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 belongs to a namespace unique from the code in your org. For more information on AppExchange Certified packages, see the 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.

Miscellaneous Apex Limits

SOQL Query Performance
For best performance, SOQL queries must be selective, particularly for queries inside triggers. To avoid long execution times, the system can terminate nonselective SOQL queries. Developers receive an error message when a non-selective query in a trigger executes against an object that contains more than 200,000 records. To avoid this error, ensure that the query is selective. See More Efficient SOQL Queries.
Chatter in Apex
For classes in the ConnectApi namespace, every write operation costs one DML statement against the Apex governor limit. ConnectApi method calls are also subject to rate limiting. ConnectApi rate limits match Chatter REST API rate limits. Both have a per user, per namespace, per hour rate limit. When you exceed the rate limit, a ConnectApi.RateLimitException is thrown. Your Apex code must catch and handle this exception.
Event Reports
The maximum number of records that an event report returns for a user who is not a system administrator is 20,000; for system administrators, 100,000.
Data.com Clean
If you use the Data.com Clean product and its automated jobs, and you have set up Apex triggers on account, contact, or lead records that run SOQL queries, the queries can interfere with Clean jobs for those objects. Your Apex triggers (combined) must not exceed 200 SOQL queries per batch. If they do, your Clean job for that object fails. In addition, if your triggers call future methods, they are subject to a limit of 10 future calls per batch.

Email Limits

Inbound Email Limits
Email Services: Maximum Number of Email Messages Processed

(Includes limit for On-Demand Email-to-Case)

 Number of user licenses multiplied by 1,000; maximum 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; maximum 1,000,000
1 The maximum size of email messages for Email Services varies depending on language and character set. The size of an email message includes the email headers, body, attachments, and encoding. As a result, an email with a 25 MB attachment likely exceeds the 25 MB size limit for an email message after accounting for the headers, body, and encoding..
When defining email services, note the following:
  • An email service only processes messages it receives at one of its addresses.
  • Salesforce limits the total number of messages that all email services combined, including On-Demand Email-to-Case, can process daily. Messages that exceed this limit are bounced, discarded, or queued for processing the next day, depending on how you configure the failure response settings for each email service. Salesforce calculates the limit by multiplying the number of user licenses by 1,000; maximum 1,000,000. For example, if you have 10 licenses, your org can process up to 10,000 email messages a day.
  • Email service addresses that you create in your sandbox cannot be copied to your production org.
  • For each email service, you can tell Salesforce to send error email messages to a specified address instead of the sender's email address.
  • Email services reject email messages and notify the sender if the email (combined body text, body HTML, and attachments) exceeds approximately 10 MB (varies depending on language and character set).
Outbound Email: Limits for Single and Mass Email Sent Using Apex

Each org can send single emails to a maximum of 5,000 external email addresses per day based on Greenwich Mean Time (GMT). For orgs created before Spring ’19, the daily limit is enforced only for emails sent via Apex and Salesforce APIs except for the REST API. For orgs created in Spring ’19 and later, the daily limit is also enforced for email alerts, simple email actions, Send Email actions in flows, and REST API. If one of the newly counted emails can’t be sent because your org has reached the limit, we notify you by email and add an entry to the debug logs. Single emails sent using the email author or composer in Salesforce don't count toward this limit. There’s no limit on sending single emails to contacts, leads, person accounts, and users in your org directly from account, contact, lead, opportunity, case, campaign, or custom object pages.

When sending single emails, keep in mind:
  • You can specify up to 100 recipients for the To field and up to 25 recipients for the CC and BCC fields in each SingleEmailMessage.
  • If you use SingleEmailMessage to email your org’s internal users, specifying the user’s ID in setTargetObjectId means the email doesn’t count toward the daily limit. However, specifying internal users’ email addresses in setToAddresses means the email does count toward the limit.

You can send mass email to a maximum of 5,000 external email addresses per day per org based on Greenwich Mean Time (GMT).

  • The single and mass email limits don't take unique addresses into account. For example, if you have johndoe@example.com in your email 10 times, that counts as 10 against the limit.
  • You can send an unlimited amount of email to your org’s internal users, which includes portal users.
  • You can send mass emails only to contacts, person accounts, leads, and your org’s internal users.
  • In Developer Edition orgs and orgs evaluating Salesforce during a trial period, you can send mass email to no more than 10 external email addresses per day. This lower limit doesn’t apply if your org was created before the Winter ’12 release and already had mass email enabled with a higher limit. Additionally, your org can send single emails to a maximum of 15 email addresses per day.

Note

Push Notification Limits

The maximum push notifications allowed for each mobile app associated with your Salesforce org depends on the type of app.
Mobile application type Maximum notifications per app per day
Provided by Salesforce (for example, Salesforce for iOS) 50,000
Developed by your company for internal employee use 35,000
Installed from the AppExchange 5,000

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.