Fix Guides

How to Fix Salesforce Apex Governor Limits

Step-by-step fix guide with AI-powered diagnosis from BuildForce.

Common Limit Errors

• TOO_MANY_SOQL_QUERIES: 101 SOQL queries per transaction. Usually a query inside a for-loop.
• TOO_MANY_DML_ROWS: 10,000 DML rows per transaction. Bulk job processing too many records in one go.
• TOO_MANY_DML_STATEMENTS: 150 DML statements per transaction. Update inside a for-loop.
• Apex CPU time exceeded: 10,000ms sync, 60,000ms async. Computationally heavy logic or recursive triggers.
• Apex heap size exceeded: 6 MB sync, 12 MB async. Holding too many records or large blobs in memory.

Fix Patterns

1. 1. Bulkify queries. Replace per-record SOQL with one query that fetches everything needed for the batch, indexed into a Map by Id.
2. 2. Aggregate DML. Build a List per object type during iteration; call insert/update once at the end.
3. 3. Selective queries. Always include a selective WHERE clause on an indexed field. Non-selective queries hit the query-timeout limit and consume governor budget.
4. 4. Move expensive work async. @future for callouts, Queueable for chained logic, Batch Apex for >50K records.
5. 5. Guard against recursion. Use a static Set<Id> in a helper class to track which record IDs have already been processed in the current transaction.
6. 6. Use Limits class for safety. Check Limits.getQueries() < Limits.getLimitQueries() before expensive operations in long-running async jobs.

Example: Trigger Bulkification

// BAD — SOQL in a loop
for (Account a : Trigger.new) {
    Contact c = [SELECT Id FROM Contact WHERE AccountId = :a.Id LIMIT 1];
    // ...
}

// GOOD — one query, then iterate
Set<Id> accountIds = (new Map<Id, Account>(Trigger.new)).keySet();
Map<Id, Contact> contactsByAccount = new Map<Id, Contact>();
for (Contact c : [SELECT Id, AccountId FROM Contact WHERE AccountId IN :accountIds]) {
    contactsByAccount.put(c.AccountId, c);
}
for (Account a : Trigger.new) {
    Contact c = contactsByAccount.get(a.Id);
    // ...
}

FAQ