Salesforce governor limits are rules that cap resource usage in Apex code to protect the multi-tenant environment. Because many customers share the same server resources, Salesforce enforces limits to prevent any single org’s code from hogging databases, memory, CPU, or network bandwidth.

For example, there’s a limit on how many queries or DML operations you can perform in one transaction. If a governor limit is exceeded, Salesforce immediately throws a runtime exception that cannot be caught – the execution halts. These limits ensure fairness and stability, but they can frustrate developers when hit unexpectedly. Below, we’ll discuss common governor limit errors and how to debug and fix them.

Common Salesforce Governor Limit Errors

"Too Many SOQL Queries: 101" (SOQL Query Limit)

Salesforce allows at most 100 SOQL queries per synchronous Apex transaction. Exceeding this causes a System.LimitException. This often happens when a SOQL query is placed inside a loop, causing each iteration to run a query. The solution is to refactor the code to bulkify queries, i.e., move SOQL outside loops and query once for all needed data.

"Too Many DML Statements: 151" (DML Statements Limit)

Similar to queries, there’s a limit of 150 DML operations (inserts/updates/deletes) per Apex transaction. This typically occurs by doing DML inside a loop. The fix is to use collections for DML – accumulate records in a list and perform one bulk insert/update at the end.

"Apex CPU time limit exceeded" (CPU Time Limit)

Salesforce limits the CPU time a transaction can use. In a synchronous context, the limit is 10,000 milliseconds. If your Apex code runs longer, you’ll get this error. Common causes include large loops, inefficient algorithms, or recursive logic. To avoid this, optimize your code, reduce loop iterations, or offload processing to asynchronous jobs.

"Apex heap size too large" (Heap Size Limit)

Salesforce enforces a heap limit of 6 MB for synchronous and 12 MB for asynchronous transactions. If your code accumulates too much data in memory, you’ll hit this error. Prevent this by querying only needed fields, processing in small batches, and using SOQL for loops or Batch Apex.

"Too many callouts: 101" (Callout Limit)

A single transaction can perform up to 100 external callouts. This error often occurs when making callouts inside a loop. Resolve this by batching records using Batch Apex, or aggregating data for fewer callouts if the external system supports bulk input.

Debugging Techniques for Governor Limit Errors

• Check Debug Logs: Look for lines showing resource usage and exception stack traces. Logs indicate what was running before the error occurred.
• Developer Console Analysis: Use Execution Overview to track limits and analyze SOQL, DML, and CPU usage. Insert System.debug statements with Limits methods to monitor real-time consumption.
• Checkpoints and Heap Inspector: Set checkpoints to view heap size and object states. This helps with diagnosing memory-related errors.
• Isolate in Execute Anonymous: Reproduce logic in a controlled script to pinpoint the source of the error without noise from other processes.

Examples of Violations and Fixes

Example 1: SOQL Inside a Loop

Violation: The code below performs a SOQL query inside a loop. If contacts contain more than 100 records, this will run a query for each contact and hit the SOQL limit.

// BAD Practice: SOQL query inside a loop
for (Contact c : contacts) {
    // Querying related Account for each contact (inefficient!)
    Account acc = [SELECT Name, Industry FROM Account WHERE Id = :c.AccountId];
    // ... (do something with acc)
}

Fix

On a large data set, the above will throw “Too many SOQL queries: 101” as soon as the 101st query executes. The fix is to bulkify the code by moving the query outside the loop, querying all needed Accounts in one go, and using a collection (map) for lookup:

// GOOD Practice: Bulkified query outside the loop
// Gather all AccountIds from contacts
Set acctIds = new Set();
for (Contact c : contacts) {
    acctIds.add(c.AccountId);
}
// Query all relevant Accounts in one query
Map accounts = new Map(
    [SELECT Name, Industry FROM Account WHERE Id IN :acctIds]
);
// Loop through contacts and use the map to get corresponding Account
for (Contact c : contacts) {
    Account acc = accounts.get(c.AccountId);
    // ... (do something with acc)
}

Example 2: DML Inside a Loop (DML Limit Violation)

Violation: This code creates a new Task for each contact and inserts it inside the loop:

// BAD Practice: DML inside a loop
for (Contact c : contacts) {
    Task t = new Task(WhoId = c.Id, Subject = 'Follow Up');
    insert t;  // DML operation in loop
}

Fix

If contacts has over 150 records, the 151st insert will hit the DML limit and throw “Too many DML statements: 151”. The best practice is to batch these DML operations by using a list:

// GOOD Practice: Bulk DML with a list
List tasksToInsert = new List();
for (Contact c : contacts) {
    Task t = new Task(WhoId = c.Id, Subject = 'Follow Up');
    tasksToInsert.add(t);  // add to list instead of inserting immediately
}
if (!tasksToInsert.isEmpty()) {
    insert tasksToInsert;  // single bulk DML for all tasks
}

Prevention Best Practices for Governor Limits

• Bulkify Your Code: Always design your code (especially triggers) to handle multiple records at once, rather than one at a time.
• No SOQL/DML in Loops: Never put a database query or DML statement inside a for loop. Instead, gather all needed data first, then perform a single operation.
• Optimize SOQL Queries: Make your queries selective and efficient. Retrieve only the fields you need and filter records using WHERE clauses.
• Use Collections and Maps: Leverage Lists, Maps, and Sets to process data in-memory and in bulk. This avoids redundant operations and speeds up execution.
• Use Asynchronous Processing: If a process hits limits in synchronous context, offload it to asynchronous Apex like Future methods, Queueable, or Batch Apex.
• Monitor and Test at Scale: Review debug logs or use Limits methods. Simulate bulk operations in tests to ensure your code scales well and avoids limits.

If your team continues to face governor limit issues despite applying bulkification and asynchronous processing, it may be time to escalate through Salesforce support channels for deeper investigation.

By following these practices, Apex developers can prevent most governor limit problems. Always think about scale, and design your code with the assumption that it might process large data volumes in real-world scenarios. This helps you stay within limits and ensures smooth, efficient Salesforce performance.