Introduction
Salesforce is based on multi-tenant architecture, which means multiple organisation share the same resources. And Governor Limit plays a very important role for all Salesforce developers.
To ensure fair resource allocation and to prevent any one organisation from consuming too many resources, Salesforce enforces governor limits. These limits are essential for maintaining system performance and stability, but it can be challenging for developers if not properly managed.
In this blog post we will explore:
- What are Governor limits?
- Why they exist?
- What happens if you exceed Governor Limits?
- Types of Salesforce Governor Limits.
What are Governor Limits?
Governor limits are restriction set by Salesforce to ensure that Salesforce resources are shared efficiently in its cloud based environment.
These limits applies to various Salesforce operations such as – number of SOQL queries, DML operations, CPU time used in a single transaction and many more.
If any process exceeds these limits, then Salesforce will throw a runtime error and that transaction will fail.
Why do Governor Limits exist?
Governor limits ensures that every user and organisation in Salesforce’s multi-tenant environment gets equal access to resources.
Governor limits are essential for maintaining the performance, security and reliability of Salesforce’s multi tenant architecture.
They help in preventing system overload, performance bottlenecks, avoids server crashes and protects Salesforce’s infrastructure from being overloaded by inefficient and excessive code.
What happens if you exceed Governor Limits?
Exceeding Governor limits may lead to exceptions, and your transaction will fail.
For example: if you exceed the SOQL query limit in a single transaction, Salesforce will throw a Too Many SOQL queries : 101 exception and the transaction will fail.
Types of Salesforce Governor Limits:
There are basically 6 types of Governor limits imposed by Salesforce. They are:
- Apex Transaction Limits
- SOQL and SOSL Query Limits
- Asynchronous Apex Limits
- API Call Limits
- Static Apex Limits
- Email and Batch Processing Limits
Lets learn about each of these limits in detail.
1. Apex Transaction Limits
- Apex is Salesforce’s server side language, used for business logic execution. Each time any Apex transaction runs, Salesforce enforces limits to ensure efficient resource usage..
Key limits per synchronous and asynchronous transaction:
- No of SOQL Queries:
100Â SOQL queries can be executed per Synchronous transaction & 200 SOQL queries can be executed per Asynchronous transaction. - No of SOSL Queries:
20 SOSL queries can be executed per Synchronous transaction & 20 SOSL queries can be executed per Asynchronous transaction. - No of DML Statements:
150 DML statements can be executed per synchronous or asynchronous transaction. - Heap Size:
6MB for synchronous transaction and 12 MB for Asynchronous transaction. - Maximum execution time:
10 minutes per synchronous transaction and 10 minutes per asynchronous transaction. - CPU Time:
10 seconds for synchronous transaction, 60 seconds for Asynchronous transaction - HTTP Callouts:
Maximum of 100 callouts per transaction is allowed.
These are the Apex Transaction limits imposed by Salesforce.Â
2. SOQL and SOSL Query Limits
Salesforce restricts the number of SOQL (Salesforce Object Query Language) and SOSL (Salesforce Object Search Language) queries to maintain database efficiency..
Key SOQL and SOSL Limits are:
- SOQL Query Rows:
Upto 50,000 rows per transaction. - SOSL Query Rows:
2000 rows per transaction. - Total SOQL queries and SOSL queries:Â
You can execute upto 100 SOQL queries per transaction and 20 SOSL queries per transaction. - Maximum SOQL query run time before Salesforce cancels the transaction: 120 seconds
- Maximum number of rows skipped by OFFSET clause:
The maximum offset is 2000 rows.
3. Asynchronous Apex Limits
Salesforce imposes Governor limit also on Asynchronous Apex. In Salesforce, we have 4 different types of Asynchronous Apex, they are –
- Future Method
- Batch Apex
- Queueable Apex
- Schedule Apex
If you’re not familiar with the Asynchronous Apex concepts mentioned above, I recommend exploring the posts linked below for a deeper understanding.
Once done, you can return to continue with this topic.
Some of the Key Limits are:
- Maximum number of methods with @future annotation allowed per Apex invocation:Â 50 methods
- Maximum number of Apex jobs added to the queue with System.enqueueJob: 50 jobs can be enqueued in a single transaction.
- The maximum number of asynchronous Apex method executions (batch Apex, future methods, Queueable Apex, and scheduled Apex) per a 24-hour period : 250,000Â or the number of user licenses in your org multiplied by 200, whichever is greater
- Number of apex classes scheduled concurrently: 100, in Developer org the limit is 5.
- Maximum number of batch apex jobs in Apex flex queue that are in Holding status: 100
- Total number of records retrieved by Database.getQueryLocator: 10,000.
- Maximum number of batch apex jobs queued or active concurrently: 5
- Maximum number of batch apex start method concurrent execution: 1
- Maximum number of batch jobs that can be submitted in a running test: 5
4. API Call Limits
Salesforce also restricts the number of API calls to prevent overload on Salesforce’s server
Key API Call Limits are:
- API Call Limit:Â The number of allowed API calls in a 24-hour period depends on your Salesforce edition.
For example: Enterprise Edition offers 1,00,000 API calls everyday. - Total number of callouts (HTTP requests or web services calls) in a transaction: 100 callouts are allowed in both Synchronous and Asynchronous transaction.
- 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
- Maximum number of Apex jobs added to the queue with System.enqueueJob: 50
5. Static Apex Limits
Salesforce has set some more restrictions on Apex which needs to be understood while writing any apex class.
Key Limit:
- Default timeout of callouts (HTTP requests or Web services calls) in a transaction: 10 seconds
- Maximum size of callout request or response: 6 MB for synchronous Apex or 12 MB for asynchronous Apex
- Maximum SOQL query run time before Salesforce cancels the transaction: 120 seconds
- Apex trigger batch size: 200
- For loop list batch size: 200
- Maximum number of records returned for a Batch Apex query in Database.QueryLocator: 50 million
6. Email and Batch Processing Limits
In Salesforce, there are restrictions on email and batch processing
Some Key Limits are:
- Email Limit: For example: In Enterprise edition, you can send upto 5000 single emails per day.
- Total number of sendEmail methods allowed: 10.
- Batch Limit:Â In Salesforce you can have 5 batch jobs running at the same time.
Now, to stay within Governor Limits, developers need to follow the best practises while coding.
Checkout the below post – which highlights the best practises that developers have to follow so that they never get hit by Governor limit again.
Conclusion
Now that you understand what Governor Limits are and the various limits imposed by Salesforce, it’s time to explore the best practices every Salesforce developer should follow to stay within these limits.
Be sure to check out the post below to dive deeper into these essential practices:
