What are governor limits in Salesforce?

Salesforce strictly applies Governor limits on the runtime Engine to keep a check on the code utilization in any org. It makes sure the resources are not monopolized by any particular organization. No particular organization shall take up all cloud CPU by writing bad code or DML statements and making others suffer. All the Apex code and other execution should occur within the predefined limits otherwise resulting in a runtime error.

Why Governor limits are introduced in Salesforce

Salesforce implements Multi-tenant Architecture to share IT resources efficiently and cost-effectively. Imagine it as a big Apartment, and there are multiple tenants living in that Apartment. No tenant should over-utilize resources like water, electricity, etc making others suffer. 

Governor limits in Salesforce

Similarly, Salesforce applies governor limits to make sure no tenant(Business, Organizations, etc) over-utilize the resource and making others suffer.

Types of governor limits in Salesforce

Types of Governor Limits

Per-Transaction Apex Limits:

These limits count for each and every Apex transaction. For Batch Apex, these limits get reset for each execution of a batch of records in the execute method.

Total number of SOQL queries issued100
Total number of records retrieved by SOQL queries50,000
Total number of records retrieved by Database.getQueryLocator10,000
Total number of SOSL queries issued20
Total number of records resulting from a single SOSL query2000
Total number of DML statements issued150
Total number of records processed by DML statements, Approval.process, or database.emptyRecycleBin10,000
Maximum methods with the future annotation allowed per Apex invocation50
Maximum  push notifications that can be sent in each push notification method call10
Maximum callouts (HTTP requests or Web services calls) in a transaction100

Per-Transaction Certified Managed Package Limits:

managed packages which have already passed the security review for AppExchange for the most transaction limits are called Certified Managed Package. These packages are installed in your org from AppExchange having unique namespaces and are developed by Salesforce ISV partners. This governor limit checks that the number of operations which can be performed in a single namespace shouldn’t exceed the per-transaction limits. Also, the collective number of operations that can be made across namespaces in any transaction is limited.

DescriptionCumulative Cross-Namespace Limit
Most number of SOQL queries issued1,100
Most number of records retrieved by Database.getQueryLocator110,000
Most number of SOSL queries issued220
Most number of DML statements issued1,650
Most number of callouts (HTTP requests or Web services calls) in a transaction1,100
Most number of sendEmail methods allowed110

Lightning Platform Apex Limits:

The limits in this table are enforced by Lightning.

Total number of Apex classes scheduled concurrently100. Limit in Developer edition is 5
Total number of batch Apex jobs in the Apex flex queue that is in Holding status100
Total number of batch Apex jobs queued or active concurrently5
Total number of batch Apex job start method concurrent executions1
Total number of batch jobs that can be submitted in a running test5

Static Apex Limits:

There are additional Governor Limits for Static Apex such as different callouts, queries, loops, records, batch sizes, etc. Let us look at them in detail:

normal timeout of callouts (HTTP requests or Web services calls) in a transaction10 seconds
Top size of an HTTP request or Web services call request or responsesynchronous Apex 6MB and asynchronous Apex 12 MB
SOQL query runtime before transaction gets canceled120 seconds
Maximum class and trigger code units present in deployment of Apex5,000
For loop list batch size200
Database.QueryLocator in Batch Apex query returns maximum records of50 million

Size-Specific Apex Limits:

The size-specific Apex Limits are specifically for making sure that there are no over-sized elements present in a class, trigger, org, etc.

Maximum number of characters for a class1 million
Maximum number of characters for a trigger1 million
All Apex code in an org can have maximum code of16 MB
Method size limit 265,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). Namespace codes are unique from the code in your org. For more information on AppExchange Certified packages, see the AppExchange online help. This limit does not imply on codes included in a class defined with the @isTest annotation.

2 Very  Large methods that could hit the allowed limit cause an exception to be thrown during the execution of your code.

How to Avoid Governor limits

1. Bulkify the Apex code: It means while writing the Apex code, a developer should ensure that the code could handle more than 1 record at a time. In case a batch invokes the Apex class then the class should be able to handle the records present in a batch.

Let’s take an example to understand:

Poor coding:

trigger accountTriggr on Account (before insert, before update) {
   //this Trigger will handle only one record and will fail in case of bulk records.
Account acc = Trigger.new[0];
List<Contact> contacts = [select id,firstname, lastname,
              from Contact where accountId = :acc.Id];

Good Coding:

trigger accountTriggr on Account (before insert, before update) {
List<String> accountNms = new List<String>{};
   //Loop through all records in the Trigger.new collection
   for(Account a: Trigger.new){
      a.Description = a.Name + ':' + a.status

2. Avoid SOQL Queries or DML statements inside FOR Loops: There is a governor limit on the number of SOQL queries and also on the number of DML statements. When these two are used in a for loop, database statements are issued for each iteration and can reach the governor limits. Let us see an example:

Poor Coding:

trigger accountTriggr on Account (before insert, before update) {
   for(Account a: Trigger.new) {
//inefficient SOQL statement within for loop
      List<Contact> contacts = [select id, firstname, lastname
                        from Contact where accountId = :a.Id];       
      for(Contact c: contacts) {
         c.Description= c.firstName + ' ' + c.lastname;    
//inefficient DML statement within for loop    
         update c;

Good Coding:

trigger accountTriggr on Account (before insert, before update) {
  //This fetches all Contacts related to Account records in a single SOQL query.
  //This is also an example of how to use child relationships in SOQL
  List<Account> accountsWithContacts = [select id, name, (select id, salutation, description,firstname, lastname from Contacts)from Account where Id  IN :Trigger.newMap.keySet()];
  List<Contact> contactsToUpdate = new List<Contact>{};
  // Use For loop to iterate through all the queried records
  for(Account a: accountsWithContacts){
     //child relationships dot fieldname syntax to access the related Contacts
     for(Contact c: a.Contacts){
      c.firstName + ' ' + c.lastname;
   perform a single Update DML statement ouside the for loop
   update contactsToUpdate;

3. One trigger per Object: Avoid using multiple triggers on the same object. If there is more than one trigger on an object they will all share the same governor limit. Example: if there can be 100 queries in a single trigger, in case of 4  triggers on account, they all have a common 100 queries.

4. Avoid hardcoding IDs in test Class:  If you hardcode IDs in the test class, you could face error while deploying the code to production or other org. Test class will also fail in case the record is deleted.

For Detailed info on the best practices, please check  click here

For Latest Salesforce interview Questions read Salesforce Interview questions you must know in-2020


Execution Governors and Limits

Categories: Salesforce Blog


Did you Like the content? Let me know