Getting Started With Governor Limits in
Salesforce (Updated 2023)
Most of you probably know that Salesforce is a multitenant environment shared by
hundreds of organizations and users worldwide. And just like in any infrastructure, its
resources aren’t infinite.
It’s no surprise that some challenges often occur when it comes to distributing and
using these resources wisely. So, since they are bounded, the platform established so-
called governor limits, making sure the Salesforce servers aren’t overused and are
shared fairly.
In this article, we’ll show you the existing governor limits for Salesforce and give a
couple of tips on how to comply with them.
What Are Governor Limits in Salesforce?
Giving a definition of Salesforce governor limits, they are sets of rules and regulations
that restrict the monopolistic use of the resources on the cloud by this or that
organization that utilizes Salesforce servers.
Such limitations (aka governors) prevent the abuse of the resources (such as memory,
database, number of processed records and script statements, etc.) by establishing
constraints that restrict the implementation of code and Apex runtime. Put simply, when
explaining what is the use of governor limits in Salesforce, this also means that the
executed code should be written optimally in terms of resource usage.
When a governor limit is surpassed or violated, Salesforce shows an error and pauses
the process that caused the error. If you've already faced these limits and they caused
disruptions in the SF Production Org, you might need the APEX code review and
optimization. Turn to our Salesforce development services to make the changes
required.
Types of Salesforce Governor Limits
Here are some Apex governor limits on the Salesforce platform:
Per-Transaction Apex Limits (such limitations are applicable for every Apex
transaction; what’s for Batch Apex cases, limitations are reset);
Per-Transaction Certified Managed Package Limits (such limits are applied to
the packages installed to an org with a namespace, such packages were created
by SFDC partners and have successfully passed the majority transaction limit
security checks run by the AppExchange);
Lightning Platform Apex Limits (such limitations are enforced by the platform
as they aren’t particular to Apex transactions);
Static Apex Limits (restricts loop and apex trigger sizes, callout sizes and times,
trigger code unit numbers, etc.);
Size-Specific Apex Limits (as evident from the name, such limits are used to
regulate sizes so that no inappropriately sized items are used in the classes).
There are also other types of governor limits. They're called non-Apex limits:
Inbound Email Limits,
Push Notification Limits,
Governor Limits for Salesforce API Requests,
Chatter REST API Limits,
SOAP API Call Limits,
API Query Cursor Limits,
Metadata Limits,
SOQL and SOSL Governor Limits in Salesforce,
Visualforce Limits.
Synchronous vs Asynchronous Execution
An Apex code can be run in two ways: synchronously or asynchronously. With the first,
all of the code gets executed at once in a single go. In the second case, part of the
process gets executed after some time in the background as a separate thread step.
In such an async scenario, users don’t have the necessity to wait before the process gets
finished; other benefits of asynchronous execution include bigger governor limits.
Note that based on these execution types, Salesforce limits can also vary.
These limits impact both how you architect SF solutions and the way the code is written.
If the limit is exceeded, it causes an error that breaks normal code execution. Contact
our Salesforce developers to handle the issues and optimize the code to perform within
limits.
List of Governor Limits in Salesforce for Apex
Major Governor Limits
Firstly, in this small Salesforce governor limits cheat sheet, let’s overview the important
limits that everyone should know:
Overview Governor
Limit
Total number of SOSL queries issued in 20
Salesforce
DML Governor Limits in Salesforce (Total 150
number of issued statements per transaction)
Total number of records retrieved by a single 2000
SOSL query
Total number of records that were retrieved by 50000
SOQL queries
Total number of records retrieved by 10000
[Link]
Salesforce Governor Limits for heap size total 6 MB/12
MB
Per-Transaction Apex Limits
The limits in the table below are applied for every Apex transaction. In some cases, when
the limits vary depending on whether the transaction is synchronous or asynchronous,
they are indicated in separate columns.
Overview Governor Governor
Limits for Limits for
Synchronous Asynchronous
Transactions Transactions
SOQL queries issued (total 100 200
number)
Records retrieved by SOQL 50000
queries (total number)
Records retrieved by 10000
[Link]
(total number)
SOSL queries issued (total 20
number)
Records retrieved by one 2000
SOSL query (total number)
DML statements issued (total 150
number)
Records processed as a result 10000
of DML statements,
[Link], or
[Link]
(total number)
Stack depth total for any Apex 16
invocation that recursively
fires triggers because of insert,
update, or delete statements
Callouts (HTTP requests or 100
web services calls) per
transaction (total number)
Max. cumulative timeout for 120 sec.
all callouts (HTTP requests or
Web services calls) per
transaction
Max. number of methods with 50 0 in batch and
the future annotation allowed future contexts;
per Apex invocation 1 in queueable
context
Max. number of Apex jobs 50 1
added to the queue with
[Link]
Allowed sendEmail methods 10
(total number)
Heap size total 6 MB 12 MB
Max. CPU time on the 10 thousand 60 thousand
Salesforce servers milliseconds. milliseconds.
Max. execution time per Apex 10 min.
transaction
Max. number of push 10
notification method calls
allowed per Apex transaction
Max. number of push 2000
notifications that can be sent
in each push notification
method call
Per-Transaction Certified Managed Package Limits
As stated earlier, such limits are applied to third-party-developed packages installed
from the AppExchange. Certified packages have their own cumulative cross-namespace
limits applied; browse details on them in the table below.
Overview Governor
Limit
SOQL queries issued (total number) 1100
Records retrieved by [Link] 110000
(total number)
SOSL queries issued (total number) 220
DML statements issued (total number) 1650
Governor Limits in Salesforce for the total number 1100
of callouts (HTTP requests or web services calls)
per transaction
SendEmail methods allowed (total number) 110
Lightning Platform Apex Limits
The following governor limits in Salesforce refer to the limits that are handled by the
platform:
Overview Governor Limit
Max. number of asynchronous Apex 250,000 or the
method executions (these include Batch number of user
Apex Governor Limits in Salesforce, licenses in your org
future methods, Queueable Apex, and multiplied by 200,
scheduled Apex) for every 24-hour whichever is greater
period
Number of synchronous concurrent 10
transactions for long-running
transactions (which take more than 5 sec
per org.)
Max. number of concurrently scheduled 100 (note that for the
Apex classes Developer Edition,
the limit is 5)
Max. number of “Holding” status batch 100
Apex jobs in an Apex flex queue
Max. number of batch Apex jobs queued 5
or active concurrently
Max. number of batch Apex job start 1
method concurrent executions
Max. number of batch jobs that can be 5
submitted in a running test
Max. number of test classes that can be The greater of 500 or
queued within 24 hours (not applicable 10 multiplied by the
to Developer Edition) number of test classes
in the org
Max. number of test classes that can be The greater of 500 or
queued per 24-hour period (sandbox and 20 multiplied by the
Developer Edition orgs) number of test classes
in the org
Max. number of query cursors open 50
concurrently per user
Max. number of query cursors open 15
concurrently per user for the Batch Apex
start method
Max. number of query cursors open 5
concurrently per user for the Batch Apex
execute and finish methods
Static Apex Limits
The following table on static Apex limits collects the extra restrictions regarding Apex
callouts, queries, records, and when there’s more than one transaction.
Overview Governor Limit
Default timeout of callouts (HTTP 10 sec.
requests or Web services calls) in a
transaction
Max. size of callout request or 6 MB for synchronous
response (HTTP request or Web Apex | 12 MB for
services call) asynchronous Apex
Max. SOQL query run time prior to 120 sec.
transaction cancellation by Salesforce
Max. number of class and trigger 5000
code units in Apex deployment
Batch size of Apex trigger 200
Batch size for loop list 200
Max. record number returned for a 50 000 000
Batch Apex query in
[Link]
Size-Specific Apex Limits
The limits in the following table restrict the sizes indicated within the Apex code,
including the number of characters and method size.
Overview Governor Limit
Max. number of characters for a 1 000 000
class
Max. number of characters for a 1 000 000
trigger
Max. amount of code used by all 6 MB
Apex code in an org
Method size limit 65,535 bytecode instructions
in compiled form
How to Bypass Salesforce Governor Limits
Imagine the following scenario: your code is highly efficient, but you still come across
situations when you can’t perform the action that you need due to the limits. This is
exactly when the question of how to avoid governor limits in Salesforce arises.
There are several ways of getting around the limits, including via asynchronous
processing like queueables, time-based workflow rules, future methods, and
batches, as well as by publishing Platform events (the last is stated among the best
solutions).
Mentioning other tips for overcoming the limits, if you’re planning to work with over
50k records, it is wise to make use of Batch Apex. Plus, it is considered good practice
to bulkify code and avoid SOQL queries and the use of DML statements within a
loop (collections or streamlining queries are better choices for this).
The above-stated practices will make your code scalable and reusable without violating
SF governor limits. Contact our certified consultants to fix your application with versatile
code which doesn't hit the limits imposed by Salesforce.