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.
Total number of SOQL queries
issued1 (This limit doesn’t apply to custom metadata types. In a
single Apex transaction, custom metadata records can have unlimited SOQL
queries.) |
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 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 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. 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.
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.
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 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. These DML
statements are in addition to the 150 DML
statements your organization’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 organization
both execute. Similarly, the certified managed package gets its own 100-SOQL-query limit for synchronous Apex, in addition to the
organization’s native code limit of 100
SOQL queries.
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 organization. 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.
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.
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 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 |
Maximum simultaneous requests to URLs with the same host for a callout
request7
|
To external endpoints: 20
To endpoints within your Salesforce org’s domain: unlimited
|
1 For Batch Apex, method executions
include executions of the start, execute, and finish methods. This limit is for your entire
organization and is shared with all asynchronous Apex: Batch Apex, Queueable 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 more requests are made while the 10 long-running requests 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 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 each for the Batch Apex
execute and finish methods, and 5 Visualforce cursors open at the same
time.
7The 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 is thrown.
Static Apex Limits
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
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 belongs 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, 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 100,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, 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. The size of an
email message includes the email headers, body, attachments, and encoding. As a result, an
email with a 25 MB attachment would likely exceed the 25 MB total size limit for an email
message, after accounting for the size of 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, 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 addresses 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:
Personal, Contact Manager, and Group Editions |
Mass email not available |
Professional Edition |
250 |
Enterprise Edition |
500 |
Unlimited and Performance Edition |
1,000 |
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.
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.