Governor Limits in salesforce are of different types for different types of resources like:

1. Per Transaction Apex limits: These limits count for each Apex transaction.

2. Per Transaction certified Managed Package Limits: Certified managed packages are the managed packages that have passed the security review for AppExchange.

3. Lightning Platform Apex Limits: Limits enforced by the Lightning Platform.

4. Static Apex Limits
5. Size Specific Apex Limits

Execution Governors and 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.

The Apex limits, or governors, track and enforce the statistics outlined in the following tables and sections.

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

In addition to the core Apex governor limits, email limits and push notification limits are also included later in this topic for your convenience.

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’re different. Otherwise, this table lists only one limit that applies to both synchronous and asynchronous Apex.

1. In a SOQL query with parent-child relationship subqueries, each parent-child relationship counts as an extra query. These types of queries have a limit of three times the number for top-level queries. The limit for subqueries corresponds to the value thatLimits.getLimitAggregateQueries() returns.The row counts from these relationship queries contribute to the row counts of the overall code execution. This limit doesn’t apply to custom metadata types. In a single Apex transaction, custom metadata records can have unlimited SOQL queries. In addition to static SOQL statements, calls to the following methods count against the number of SOQL statements issued in a request.

• Database.countQuery
• Database.getQueryLocator
• Database.query

2. Calls to the following methods count against the number of DML statements issued in a request.

• Approval.process
• Database.convertLead
• Database.emptyRecycleBin
• Database.rollback
• Database.setSavePoint
• delete and Database.delete
• insert and Database.insert
• merge and Database.merge
• undelete and Database.undelete
• update and Database.update
• upsert and Database.upsert
• EventBus.publish
• System.runAs

3. Recursive Apex that does not fire any triggers with insert, update, or delete statements exists in a single invocation, with a single stack. Conversely, recursive Apex that fires a trigger spawns the trigger in a new Apex invocation, separate from the invocation of the code that caused it to fire. Because spawning a new invocation of Apex is a more expensive operation than a recursive call in a single invocation, there are tighter restrictions on the stack depth of these types of recursive calls.

4. Email services heap size is 36 MB.

5. CPU time is calculated for all executions on the Salesforce application servers occurring in one Apex transaction. CPU time is calculated for the executing Apex code, and for any processes that are called from this code, such as package code and workflows. CPU time is private for a transaction and is isolated from other transactions. Operations that don’t consume application server CPU time aren’t counted toward CPU time. For example, the portion of execution time spent in the database for DML, SOQL, and SOSL isn’t counted, nor is waiting time for Apex callouts.

• Limits apply individually to each testMethod.
• To determine the code execution limits for your code while it is running, use the Limits methods. For example, you can use the getDMLStatements method to determine the number of DML statements that have already been called by your program. Or, you can use thegetLimitDMLStatements method to determine the total number of DML statements available to your code.

Per-Transaction Certified Managed Package Limits

Certified managed packages—managed packages that have passed the security review for AppExchange—get their own set of limits for most per-transaction limits. Certified managed packages are developed by Salesforce ISV Partners, are installed in your org from Salesforce AppExchange, and have unique namespaces.

Here is an example that illustrates the separate certified managed package limits for DML statements. If you install a certified managed package, all the Apex code in that package gets its own 150 DML statements. These DML statements are in addition to the 150 DML statements your org’s native code can execute. This limit increase means more than 150 DML statements can execute during a single transaction if code from the managed package and your native org both execute. Similarly, the certified managed package gets its own 100-SOQL-query limit for synchronous Apex, in addition to the org’s native code limit of 100 SOQL queries.

There’s no limit on the number of certified namespaces that can be invoked in a single transaction. However, the number of operations that can be performed in each namespace must not exceed the per-transaction limits. There’s also a limit on the cumulative number of operations that can be made across namespaces in a transaction. This cumulative limit is 11 times the per-namespace limit. For example, if the per-namespace limit for SOQL queries is 100, a single transaction can perform up to 1,100 SOQL queries. In this case, the cumulative limit is 11 times the per-namespace limit of 100. These queries can be performed across an unlimited number of namespaces, as long as any one namespace doesn’t have more than 100 queries. The cumulative limit doesn’t affect limits that are shared across all namespaces, such as the limit on maximum CPU time.

These cross-namespace limits apply only to namespaces in certified managed packages. Namespaces in packages that are not certified don’t have their own separate governor limits. The resources they use continue to count against the same governor limits used by your org’s custom code.

This table lists the cumulative cross-namespace limits.

All per-transaction limits count separately for certified managed packages except for:

• The total heap size
• The maximum CPU time
• The maximum transaction execution time
• The maximum number of unique namespaces

These limits count for the entire transaction, regardless of how many certified managed packages are running in the same transaction.

Also, if you install a package from AppExchange that isn’t created by a Salesforce ISV Partner and isn’t certified, the code from that package doesn’t have its own separate governor limits. Any resources it uses count against the total governor limits for your org. Cumulative resource messages and warning emails are also generated based on managed package namespaces.

For more information on Salesforce ISV Partner packages, see Salesforce Partner Programs.

Lightning Platform Apex Limits

The limits in this table aren’t specific to an Apex transaction and are enforced by the Lightning Platform.

1. For Batch Apex, method executions include executions of thestart, execute, and finish methods. This limit is for your entire org and is shared with all asynchronous Apex: Batch Apex, Queueable Apex, scheduled Apex, and future methods. To check how many asynchronous Apex executions are available, make a request to the REST API limits resource. See List Organization Limits in the REST API Developer Guide. The licenses that count toward this limit are full Salesforce user licenses or App Subscription user licenses. Chatter Free, Chatter customer users, Customer Portal User, and partner portal User licenses aren’t included.

2. If more transactions are started while the 10 long-running transactions are still running, they’re denied.

3. When batch jobs are submitted, they’re held in the flex queue before the system queues them for processing.

4. Batch jobs that haven’t started yet remain in the queue until they’re started. If more than one job is running, this limit doesn’t cause any batch job to fail and execute methods of batch Apex jobs still run in parallel.

5. This limit applies to tests running asynchronously. This group of tests includes tests started through the Salesforce user interface including the Developer Console or by inserting ApexTestQueueItemobjects using SOAP API.

6. For example, if 50 cursors are open and a client application still logged in as the same user attempts to open a new one, the oldest of the 50 cursors is released. Cursor limits for different Lightning Platform features are tracked separately. For example, you can have 50 Apex query cursors, 15 cursors for the Batch Apex startmethod, 5 cursors each for the Batch Apex execute and finishmethods, and 5 Visualforce cursors open at the same time.

Static Apex Limits

1. The HTTP request and response sizes count towards the total heap size.

Size-Specific Apex Limits

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

6. Miscellaneous Limits

Per Transaction Apex limits

Some of the important per transaction limits are: