Salesforce Governor Limits, explained simply

Salesforce works the same way. Thousands of companies run on the same servers, which is called multi-tenancy. To keep it fair, Salesforce caps how much any one piece of code can use. Those caps are the governor limits.

If your code crosses a limit, Salesforce stops it immediately and undoes everything that code did. You cannot catch this error with try/catch, so the only real fix is to write code that stays inside the limits.

In Salesforce, a transaction starts when something runs your code: a user clicks Save, a record is inserted, or an integration calls in. It ends when all the code started by that action finishes. Most limits are counted per transaction.

There are two kinds of code. Synchronous code runs right now while the user waits, like paying at the counter. Asynchronous code runs in the background later, like home delivery. Background code gets bigger limits because nobody is waiting on it.

No need to memorise this now. Pick a group, scan it, then read the examples below. Values marked in colour are the bigger asynchronous ones.

Learn these five well and you will avoid almost every governor limit error you will ever see.

for (Contact c : contacts) {
    // one trip for EVERY contact
    Account a = [SELECT Name FROM Account
                 WHERE Id = :c.AccountId];
}

// 1. Write the shopping list
Set<Id> ids = new Set<Id>();
for (Contact c : contacts) ids.add(c.AccountId);

// 2. One trip to the database
Map<Id, Account> accs = new Map<Id, Account>(
    [SELECT Name FROM Account WHERE Id IN :ids]);

for (Opportunity o : opps) {
    o.StageName = 'Closed Won';
    update o;  // a trip per record
}

for (Opportunity o : opps) {
    o.StageName = 'Closed Won';
}
update opps;  // one trip for all

for (Opportunity o : opps) {       // 5,000
    for (Account a : accounts) {   // 5,000
        if (o.AccountId == a.Id) { }
    }
}
// 25 million checks

Map<Id, Account> accMap =
    new Map<Id, Account>(accounts);
for (Opportunity o : opps) {
    Account a = accMap.get(o.AccountId);
}
// 5,000 instant lookups

for (List<Account> chunk : [SELECT Id, Description FROM Account]) {
    // work with 200 records; they are cleared after
}

HttpRequest req = new HttpRequest();
req.setEndpoint('callout:My_ERP/orders');
req.setMethod('POST');
req.setBody(JSON.serialize(allOrders)); // everything at once
HttpResponse res = new Http().send(req);

List<Messaging.SingleEmailMessage> mails = new List<Messaging.SingleEmailMessage>();
for (Case c : cases) mails.add(buildMail(c));
Messaging.sendEmail(mails);

@future(callout=true)
public static void syncToErp(Set<Id> accountIds) {
    // handle every account here
}

trigger AccountTrigger on Account (after update) {
    List<Account> accs = new List<Account>();
    for (Account a : Trigger.new) {
        accs.add(new Account(Id = a.Id, Rating = 'Hot'));
    }
    update accs;  // fires this trigger again
}

trigger AccountTrigger on Account (before update) {
    for (Account a : Trigger.new) {
        a.Rating = 'Hot';  // saved with the record, no DML
    }
}

When you genuinely need an after trigger, remember which records you have already handled, and skip them the second time round.

public class TriggerGuard {
    public static Set<Id> done = new Set<Id>();
}

// inside the trigger
List<Account> todo = new List<Account>();
for (Account a : Trigger.new) {
    if (TriggerGuard.done.add(a.Id)) todo.add(a);  // add() is false if seen
}

Remember: Prefer a before trigger. A Set of Ids beats a single true/false flag, which silently skips the second chunk of 200.

Some limits are a daily budget shared by every user, integration and job in your org, like a family mobile data pack. If one app eats it all, everything else stops too.

@isTest
static void handles200Contacts() {
    List<Contact> cons = new List<Contact>();
    for (Integer i = 0; i < 200; i++) cons.add(new Contact(LastName = 'Test ' + i));

    Test.startTest();      // fresh limits start here
    insert cons;
    Test.stopTest();

    System.assertEquals(200, [SELECT COUNT() FROM Contact]);
}

• No SOQL in loopsCollect Ids first, query once.
• No DML in loopsChange records in a list, save once.
• Use MapsInstant lookups instead of loops in loops.
• Query only what you needFilter with WHERE, pick only the fields you use.
• Big data? Batch ApexSmall chunks, fresh limits each time.
• Slow work? Go asyncQueueable or @future for callouts and heavy logic.
• Stop recursionPrefer before triggers, or track handled Ids.
• Test with 200 recordsIf it works for 200, it works in real life.

Check your usage while coding

The Limits class is your fuel meter. The bottom of every debug log also shows how much of each limit was used.

System.debug('Queries: ' + Limits.getQueries() + ' / ' + Limits.getLimitQueries());
System.debug('DML: ' + Limits.getDmlStatements() + ' / ' + Limits.getLimitDmlStatements());
System.debug('CPU ms: ' + Limits.getCpuTime() + ' / ' + Limits.getLimitCpuTime());

Educational only. This article explains how things work. It is not investment, tax, legal or career advice, and it is not a recommendation to buy or sell anything. What suits you depends on your own situation - check with a qualified adviser before acting on money decisions.