Force.com Apex Code Developer's Guide

Clouds with binary code floating aboveCloud with binary code floating above

No Results

Search Tips:

  • Please consider misspellings
  • Try different search keywords
PDF

Newer Version Available

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

Understanding Execution Governors and Limits

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.

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 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
1 In a SOQL query with parent-child relationship sub-queries, each parent-child relationship counts as an additional query. These types of queries have a limit of three times the number for top-level queries. The row counts from these relationship queries contribute to the row counts of the overall code execution. 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 queries 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
  • 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—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.

  • Limits apply individually to each testMethod.
  • Use the Limits methods to determine the code execution limits for your code while it is running. For example, you can use the getDMLStatements method to determine the number of DML statements that have already been called by your program, or 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, 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.

All per-transaction limits count separately for certified managed packages with the exception of:
  • 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 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.

Force.com Platform Apex Limits

The limits in this table aren’t specific to an Apex transaction and are enforced by the Force.com 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 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 simultaneous requests to URLs with the same host for a callout request3 20
Maximum number of Apex classes scheduled concurrently 100
Maximum number of Batch Apex jobs queued or active 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

1 For Batch Apex, method executions include executions of the start, execute, and finish methods. This is an organization-wide limit and is shared with all asynchronous Apex: Batch Apex, scheduled Apex, and future methods. The licenses that count toward this limit are full Salesforce user licenses or Force.com App Subscription user licenses. Chatter Free, Chatter customer users, Customer Portal User, and partner portal User licenses aren’t included.

2 If additional requests are made while the 10 long-running requests are still running, they’re denied.

3 The host is defined by the unique subdomain for the URL, for example, www.mysite.com and extra.mysite.com are two different hosts. This limit is calculated across all organizations that access the same host. If this limit is exceeded, a CalloutException will be thrown.

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.

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 3 MB
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

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 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.

Miscellaneous Apex Limits

SOQL Query Performance
For best performance, SOQL queries must be selective, particularly for queries inside of triggers. To avoid long execution times, non-selective SOQL queries may be terminated by the system. Developers will receive an error message when a non-selective query in a trigger executes against an object that contains more than 100,000 records. To avoid this error, ensure that the query is selective. See More Efficient SOQL Queries.
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 with SOQL queries to run when account, contact, or lead records, the queries may interfere with Clean jobs for those objects. Your Apex triggers (combined) should not exceed 200 SOQL queries per batch. If they do, your Clean job for that object will fail. In addition, if your triggers call future methods, they will be 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, 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
1 The maximum size of email messages for Email Services varies depending on language and character set.
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, up to a daily maximum of 1,000,000. For example, if you have 10 licenses, your organization 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 organization.
  • 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

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.

When sending single emails, keep in mind:
  • You can send 100 emails per SingleEmailMessage.
  • If you use SingleEmailMessage to email your organization’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 addresseses in setToAddresses means the email does count toward the limit.
You can send mass email to a maximum of 1,000 external email addresses per day per organization based on Greenwich Mean Time (GMT). The maximum number of external addresses you can include in each mass email depends on your edition:
Edition External Address Limit per Mass Email
Personal, Contact Manager, and Group Editions Mass email not available
Professional Edition 250
Enterprise Edition 500
Unlimited and Performance Edition 1,000

Note the following about email limits:

  • 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 organization’s internal users, which includes portal users.
  • In Developer Edition organizations and organizations evaluating Salesforce during a trial period, your organization can send mass email to no more than 10 external email addresses per day. This lower limit does not apply if your organization was created before the Winter '12 release and already had mass email enabled with a higher limit. Additionally, your organization can send single emails to a maximum of 15 email addresses per day.

Note

Push Notification Limits

The maximum number of push notifications that are allowed for each mobile application associated with your Salesforce organization depends on the type of application.
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.