Salesforce allows us to process or execute a particular number of statements/records at a time. There are some limits for DML statements, Apex classes, etc., to execute or process. These limits are known as Governor limits. In this tutorial, we will see what the Governor limits are and how they can be handled. Also, Salesforce Apex provides the “Limit” class to know the limits that are related to callouts, Apex classes, lightning web components, SOSL and SOQL statements.

Governor Limits

Consider a scenario where Alish and Subash are two persons using the Salesforce org. Alice wants to process or execute 1000 DML statements  in one transaction. In parallel, Subash wants to load 5000 records at a time. If they do it in parallel, Salesforce won’t accept and becomes hectic. Hence, Governor limits come into picture. In this case, Alish can process 100 DML at a time and Subash can process 500 records at a time. They can use the AsynchronousBatch Apex to do each transaction on a separate thread without disturbing each of them and complete their task.

Basically, Governor limits in Salesforce limit the processing and execution in multiple transactions. “Per-Transaction Apex Limits” counts for each transaction and “Size-Specific Apex Limit” deals with the size of  the code. Salesforce supports two processes: synchronous and asynchronous processes. In the synchronous process, the Apex script is executed in a single go while in the asynchronous process, the Apex script is executed by splitting into multiple jobs.

Allowed Limits

Let’s discuss the limit count for different scenarios:

1. It can be possible to process/run 100 SOQL queries in synchronous Apex and 200 SOQL queries in asynchronous Apex.
2. Only 50,000 records will return from an SOQL query for both synchronous and asynchronous apex.
3. If we use the Database.getQueryLocator(), only 10,000 are returned at a time for both synchronous and asynchronous Apex.
4. In both scenarios, the number of SOSL queries issued is 20.
5. The heap size that is required to process the synchronous Apex is 6 MB. For asynchronous Apex, the heap size required is double which makes it 12 MB.
6. The maximum CPU time that is allowed for synchronous Apex is 10,000 milliseconds and 60,000 milliseconds for asynchronous Apex.
7. Only 10 minutes is allowed for the execution for both Apex.
8. In both cases, we can use only 10 sendEmail() method with 100 recipients.
9. The characters that are present in the Apex class or in Apex trigger must be within 1 million.
10. In Batch Apex (asynchronous), the size is 200. The QueryLocator() of the “Database” class returns 50 million records per transaction.
11. Only 5 Apex jobs will be in queue or active.

LIMIT Class Example:

Apex can specify the Governor limits in the “LIMIT” class. This class provides some methods that tells the Governor limits. Let’s look at the following example which displays some Governor limits:

Output:

It can also be possible to check how many DML statements/rows can be returned using the “dome” methods that are present in the “LIMIT” class.

1. Limits.getDMLStatements() returns the total DML statements that are used at an instance.
2. Limits.getDMLRows() returns the total number of rows that are returned by the DML statements.
3. Limits.getCpuTime() returns the CPU utilized time for the current transaction in milliseconds.

Usage Example:

Let’s write an SOQL query that returns the two records from the “WorkOrder” object. After that, delete these two records using “delete” DML.

Output:

In the given example, there are no DML statements and 0 rows. The existing CPU time is 1 millisecond.  After returning 2 rows from the SOQL query and deleting these two rows, the total number of DML statements that is returned by the Limits.getDMLStatements() is 1, the total rows returned by the Limits.getDMLRows()  is 2, and the CPU time that is needed to execute this transaction is 51 milliseconds.

Best Practice Example:  “NEVER USE DML INSIDE THE LOOP”

Let’s see how we can run the code without getting the governor limit. We first create a record on the “Product” object (API – Product2) from  the  “WorkOrder” object by assigning the “WorkOrder” subject to the “Product Name” in the “for” loop itself. Let’s see the following code:

We can do this in a better way by declaring a list (prod_s) and then storing the prod_obj in the list. We can insert this list into the product outside the loop.

Conclusion

We now learned what Apex limits are in Salesforce with a detailed explanation. It is better to go with the Asynchronous Apex process to gain better Governor limits when compared to Synchronous Apex. We also learned about the Governor limits for different scenarios and gave a sample demonstration regarding the limit count from the “Limit” class. We also verified the count of DML statements, rows, and CPU time by running one DML statement. We concluded this guide by discussing one best practice example.