Understanding Governor Limit & Its Types in Salesforce?

Governor Limits in Salesforce
Chinmaya By Chinmaya
10 Min Read

Introduction

Salesforce is a powerful platform that allows businesses to manage their customer relationships, automate processes, and analyze data.
However, to ensure that the platform runs smoothly and efficiently for all users, Salesforce enforces certain restrictions known as Governor Limits.

These limits are in place to prevent any single user or organization from monopolizing shared resources, which could degrade the performance of the platform for others.

In this blog post, we’ll break down what Governor Limits are, why they exist, and the different types of limits you need to be aware of when working with Salesforce.
We’ll also provide examples to help you understand how these limits work in real-world scenarios.

What are Governor Limits?

Governor Limits are runtime restrictions enforced by Salesforce to ensure that the platform remains stable, secure, and efficient for all users.
These limits are like “rules of the road” that prevent your code or processes from consuming too many resources, such as memory, CPU time, or database queries.

If your code exceeds these limits, Salesforce will throw an error, and your transaction will be halted. This ensures that no single process can negatively impact the performance of the platform for other users.

Why do Governor Limits exist?

    1. Resource Management: Salesforce is a multi-tenant platform, meaning multiple organizations share the same infrastructure. Governor Limits ensure fair usage of shared resources.

    2. Performance: By limiting how much data or processing power a single transaction can use, Salesforce maintains optimal performance for all users.

    3. Security: Limits prevent malicious or poorly written code from overloading the system.

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:

Salesforce imposes various types of Governor Limits, depending on the context of your code or process. 
There are basically 8 types of Governor Limits imposed by Salesforce. They are:

    1. Apex Transaction Limits
    2. SOQL and SOSL Query Limits
    3. Asynchronous Apex Limits
    4. API Call Limits
    5. Lightning Component Limits
    6. Static Apex Limits
    7. Email and Batch Processing Limits
    8. Data Storage Limits

Lets learn about each of these limits in detail.

1. Apex Transaction Limits

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

    1. No of SOQL Queries:
      100  SOQL queries can be executed per Synchronous transaction & 200 SOQL queries can be executed per Asynchronous transaction.
    2. No of SOSL Queries:
      20 SOSL queries can be executed per Synchronous transaction & 20 SOSL queries can be executed per Asynchronous transaction.
    3. No of DML Statements:
      150 DML statements can be executed per synchronous or asynchronous transaction.
    4. Heap Size:
      6MB for synchronous transaction and 12 MB for Asynchronous transaction.
    5. Maximum execution time:
      10 minutes per synchronous transaction and 10 minutes per asynchronous transaction. 
    6. CPU Time:
      10 seconds for synchronous transaction, 60 seconds for Asynchronous transaction
    7. HTTP Callouts:
      Maximum of 100 callouts per transaction is allowed.

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:

    1. SOQL Query Rows:
      Upto 50,000 rows per transaction.
    2. SOSL Query Rows:
      2000 rows per transaction.
    3. Total SOQL queries and SOSL queries: 
      You can execute upto 100 SOQL queries per transaction and 20 SOSL queries per transaction.
    4. Maximum SOQL query run time before Salesforce cancels the transaction: 120 seconds
    5. 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 :-

    1. Future Method
    2. Batch Apex
    3. Queueable Apex
    4. 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:

    1. Maximum number of methods with @future annotation allowed per Apex invocation: 50 methods
    2. Maximum number of Apex jobs added to the queue with System.enqueueJob: 50 jobs can be enqueued in a single transaction.
    3. 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
    4. Number of apex classes scheduled concurrently: 100, in Developer org the limit is 5.
    5. Maximum number of batch apex jobs in Apex flex queue that are in Holding status: 100
    6. Total number of records retrieved by Database.getQueryLocator: 10,000.
    7. Maximum number of batch apex jobs queued or active concurrently: 5
    8. Maximum number of batch apex start method concurrent execution: 1
    9. 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:

    1. 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.
    2. Total number of callouts (HTTP requests or web services calls) in a transaction: 100 callouts are allowed in both Synchronous and Asynchronous transaction.
    3. Maximum cumulative timeout for all callouts (HTTP requests or Web services calls) in a transaction: 120 seconds.
    4. Maximum number of methods with the future annotation allowed per Apex invocation: 50
    5. Maximum number of Apex jobs added to the queue with System.enqueueJob: 50

5. Lightning Component Limit

When building Lightning components, you need to be aware of:

    • JavaScript Heap Size:

      • Lightning components have a 5 MB JavaScript heap size limit.

      • Example: Loading too much data into a component can exceed this limit.

    • Server-Side Calls:

      • You can make up to 50 server-side calls in a single transaction.

6. Static Apex Limits

Salesforce has set some more restrictions on Apex which needs to be understood while writing any apex class.

Key Limit:

    1. Default timeout of callouts (HTTP requests or Web services calls) in a transaction: 10 seconds
    2. Maximum size of callout request or response: 6 MB for synchronous Apex or 12 MB for asynchronous Apex
    3. Maximum SOQL query run time before Salesforce cancels the transaction: 120 seconds
    4. Apex trigger batch size: 200
    5. For loop list batch size: 200
    6. Maximum number of records returned for a Batch Apex query in Database.QueryLocator: 50 million

7. Email and Batch Processing Limits

In Salesforce, there are restrictions on email and batch processing

Some Key Limits are:

    1. Email Limit: For example: In Enterprise edition, you can send upto 5000 single emails per day.
    2. Total number of sendEmail methods allowed: 10.
    3. Batch Limit: In Salesforce you can have 5 batch jobs running at the same time.

8. Data Storage Limits

Salesforce imposes limits on how much data you can store:

    • Record Storage:

      • Each org has a limit on the number of records it can store, depending on the edition (e.g., Enterprise, Unlimited).

      • Example: Storing millions of records without archiving old data can lead to storage issues.

    • File Storage:

      • Files and documents also count toward your org’s storage limit.

Checkout the below post – which highlights the best practises that developers have to follow so that they never get hit by Governor limit again.

Best practises to stay within Governor Limits
Best Practises every Salesforce Developer should follow : Writtee.com

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:

Share This Article
Follow:
Chinmaya is working as a Senior Consultant with a deep expertise in Salesforce. Holding multiple Salesforce certifications, he is dedicated to designing and implementing cutting-edge CRM solutions. As the creator of Writtee.com, Chinmaya shares his knowledge on educational and technological topics, helping others excel in Salesforce and related domains.
4 Comments