System.LimitException: Too many SOQL queries: 101 - why it happens and how to fix it

It always seems to happen at the worst moment. The code worked in the sandbox, the tests passed, and then a data load or an integration runs in production and the screen fills with red: System.LimitException: Too many SOQL queries: 101. Nothing is saved, and the error does not even say which line caused it.

This guide takes the error apart in four steps: what it is, why it happens, a real example of finding and fixing it, and a short summary to keep.

Every Apex transaction may run 100 SOQL queries when it runs synchronously - while a user waits on a save, a button or a page. The moment code asks for query number 101, Salesforce stops it with System.LimitException: Too many SOQL queries: 101.

Two things make this error painful. You cannot catch it with try/catch, and Salesforce rolls back everything the transaction did - every insert, update and email. The only fix is code that never asks for the 101st query.

The error says how many queries ran, not where they came from. In practice it is almost always one of these five.

trigger ContactTrigger on Contact (before insert) {
    for (Contact c : Trigger.new) {
        Account a = [SELECT Region__c FROM Account WHERE Id = :c.AccountId];
        c.Region__c = a.Region__c;
    }
}

for (Contact c : Trigger.new) {
    // getRegion runs a query - once per contact
    c.Region__c = AccountService.getRegion(c.AccountId);
}

Take the trigger from cause 1: it copies the region from each new contact's account. It passes every test with one contact, then fails when a data load inserts 200. Here is how you would track it down and fix it.

1. Open Setup → Debug Logs and add a trace flag for your user (or the integration user), with the Database category set to INFO or finer.
2. Run the action again - the save, the data load or the button.
3. Open the log and search for SOQL_EXECUTE_BEGIN. Every query writes one line, with the class and line number it came from.
4. The query you see over and over, from the same line, is your culprit. The end of the log also shows Number of SOQL queries: 101 out of 100.

While you are fixing it, print the count at the points you suspect. The Limits class tells you how many queries have run so far in this transaction.

System.debug('SOQL used: ' + Limits.getQueries() + ' of ' + Limits.getLimitQueries());

Fix 1: collect the Ids, query once, use a Map

Loop once to collect what you need, run one query for all of it, then loop again and read from a Map. 200 records now cost one query.

for (Contact c : Trigger.new) {
    Account a = [SELECT Region__c FROM Account WHERE Id = :c.AccountId];
    c.Region__c = a.Region__c;
}

Set<Id> accountIds = new Set<Id>();
for (Contact c : Trigger.new) accountIds.add(c.AccountId);

Map<Id, Account> accounts = new Map<Id, Account>(
    [SELECT Region__c FROM Account WHERE Id IN :accountIds]);

for (Contact c : Trigger.new) {
    Account a = accounts.get(c.AccountId);
    if (a != null) c.Region__c = a.Region__c;
}

Fix 2: make helper methods take a list

A method that takes one Id and returns one value invites being called in a loop. Give it a Set of Ids and have it return a Map - then it can only be called once.

public with sharing class AccountService {
    public static Map<Id, String> getRegions(Set<Id> accountIds) {
        Map<Id, String> regions = new Map<Id, String>();
        for (Account a : [SELECT Region__c FROM Account WHERE Id IN :accountIds]) {
            regions.put(a.Id, a.Region__c);
        }
        return regions;
    }
}

Fix 3: get related records in the same query

Instead of querying Contacts once per Account, ask for the Accounts with their Contacts in one query. The outer query counts as one SOQL query; the subquery counts toward a separate, larger limit.

for (Account a : [SELECT Id, Name, (SELECT Id, Email FROM Contacts)
                  FROM Account WHERE Id IN :accountIds]) {
    for (Contact c : a.Contacts) {
        // no extra query
    }
}

Fix 4: stop the same trigger running twice

If the debug log shows your trigger's queries twice in one save, the trigger is firing itself again. Remember which records were handled in a static Set, and skip them the second time.

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

// in the after update handler
List<Account> todo = new List<Account>();
for (Account a : (List<Account>) Trigger.new) {
    if (TriggerGuard.handled.add(a.Id)) todo.add(a); // false if already seen
}

Fix 5: fix the Flow too

Move any Get Records out of a Loop element: get all the records once before the loop, then use a collection or a filter inside it. And check whether the Flow and an Apex trigger are both doing work on the same object - often one can do the job of both.

Remember: Moving code to a Queueable job raises the limit to 200, but a query in a loop still fails at 201 records. Async is not the fix - bulkifying is.

Most SOQL 101 errors reach production because the tests use one record. Insert 200, run the code between Test.startTest() and Test.stopTest() so it gets fresh limits, and check how many queries it used.

@isTest
private class ContactTriggerTest {
    @isTest
    static void twoHundredContactsUseFewQueries() {
        Account acc = new Account(Name = 'Acme', Region__c = 'North');
        insert acc;
        List<Contact> cons = new List<Contact>();
        for (Integer i = 0; i < 200; i++) {
            cons.add(new Contact(LastName = 'Test ' + i, AccountId = acc.Id));
        }

        Test.startTest();
        insert cons;
        Integer used = Limits.getQueries();
        Test.stopTest();

        Assert.isTrue(used < 5, 'Trigger is not bulk-safe: ' + used + ' queries');
        Assert.areEqual(200, [SELECT COUNT() FROM Contact WHERE Region__c = 'North']);
    }
}

Too many SOQL queries: 101 means one transaction asked for more than its 100 queries - almost always because a query runs once per record, in a loop, a helper method, a chain of triggers or a Flow. Find the repeating line in the debug log, collect the Ids and query once into a Map, and prove it with a test that inserts 200 records.

• No SOQL in loopsCollect Ids first, query once.
• Look inside method callsA helper called in a loop is a query in a loop.
• Helpers take setsSet<Id> in, Map out - impossible to misuse.
• Use subqueriesParents and children in one query.
• Guard recursionA static Set of handled Ids.
• Count the whole saveTriggers, Flows and other triggers share 100.
• Async is not a fixIt moves the limit to 200, not away.
• Test with 200 recordsAnd assert on Limits.getQueries().

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.