Salesforce Governor Limits

What is Salesforce Governor Limits?

What are governor limits in salesforce?

Salesforce Governor Limits

Apex runtime engine strictly enforces limits to ensure that runaway Apex code or processes don’t monopolize shared resources.

Why Salesforce has Governor Limits?

Because Apex runs in a multitenant environment, the Apex runtime engine strictly enforces limits to ensure that runaway Apex code or processes don’t monopolize shared resources. If some Apex code exceeds a limit, the associated governor issues a runtime exception that cannot be handled.

Type of Governor Limits

Per-Transaction Apex Limits
Per-Transaction Certified Managed Package Limits
Lightning Platform Apex Limits
Static Apex Limits
Size-Specific Apex Limits
Miscellaneous Apex Limit

In this post we will mainly cover Per-Transaction Apex Limits.

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

This table lists limits for synchronous Apex and asynchronous Apex (Batch Apex and future methods) when they are different. Otherwise, this table lists only one limit that applies to both synchronous and asynchronous Apex. This table can be used as cheat sheet.

Here is list of important governor limits in salesforce

Total number of SOQL queries issued : 200
Total number of SOSL queries issued : 20
Total number of DML statements issued : 150
Total number of records retrieved by SOQL queries : 50,000
Total number of records processed as a result of DML statements : 10,000

Here is full list of governor limits in salesforce

Description	Synchronous Limit	Asynchronous Limit
Total number of SOQL queries issued	100	200
Total number of records retrieved by SOQL queries	50,000
Total number of records retrieved by Database.getQueryLocator	10,000
Total number of SOSL queries issued	20
Total number of records retrieved by a single SOSL query	2,000
Total number of DML statements issued	150
Total number of records processed as a result of DML statements, Approval.process, or database.emptyRecycleBin	10,000
Total stack depth for any Apex invocation that recursively fires triggers due to insert, update, or delete statements	16
Total number of callouts (HTTP requests or Web services calls) in a transaction	100
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
Total number of sendEmail methods allowed	10
Total heap size	6 MB	12 MB
Maximum CPU time on the Salesforce servers	10,000 milliseconds	60,000 milliseconds
Maximum execution time for each Apex transaction	10 minutes
Maximum number of push notification method calls allowed per Apex transaction	10
Maximum number of push notifications that can be sent in each push notification method call	2,000

For more details about governor limit, please refer to below link Execution Governors and Limits

Avoiding Governor limits

From a Developer’s perspective, it is important to ensure that our code should be scalable and should not hit the governor limits. Its very important to follow some of best practices so that our code does not hit governor limit. These are some of best practices that we should follow:

Bulkify your Code
Avoid SOQL Queries or DML statements inside FOR Loops
Bulkify your Helper Methods
Using Collections, Streamlining Queries, and Efficient For Loops
Streamlining Multiple Triggers on the Same Object
Querying Large Data Sets
Use of the Limits Apex Methods to Avoid Hitting Governor Limits
Use @future Appropriately
Use batch apex if you are working for more than 50000 records.
Never make any SOQL, DML operation inside the loop.

For more details, refer this APEX best Practices

For other Salesforce post, please refer this link

Salesforce Governor Limits