This guide explains what the Salesforce error System.LimitException: Too many SOQL queries: 101 means, why it shows up, and how to fix it without ritual sacrifices to the Apex gods. It’s written for Salesforce Admins, RevOps, and Business Systems teams who want a repeatable troubleshooting workflow. (And yes, it’s also part of the same “errors that break Agentforce” universe of problems.)
TL;DR
- This error means your transaction executed more than 100 SOQL queries (in a synchronous context).
- The most common causes are queries inside loops, Flow Get Records inside loops, and recursion (Trigger ↔ Flow ↔ Trigger)
- Fix it with a workflow: reproduce → find the query sources → identify the fan-out → refactor/bulkify → retest.
- Long term, “101” is a symptom of metadata debt: too many automations nobody can reason about end-to-end.
What “Too Many SOQL Queries: 101” Actually Means
Salesforce enforces governor limits to protect shared resources. One of the most common: a maximum of 100 SOQL queries per transaction in synchronous execution. When your request hits query #101, Salesforce stops the transaction and throws:
System.LimitException: Too many SOQL queries: 101 Salesforce
Key point: this isn’t a “sometimes” limit. It’s a hard stop.
The Usual Culprits (It’s Not Always “Apex In A Loop”)
1) Queries inside loops (Apex)
The classic anti-pattern:
for (Account a : accounts) { List<Contact> cs = [SELECT Id FROM Contact WHERE AccountId = :a.Id]; }
One loop iteration = one query. One batch of 200 records = pain.
2) Get Records inside loops (Flow)
Flow can create the same failure mode: a Get Records executed repeatedly inside a loop. It often “works in sandbox” and dies in production because production has… volume.
3) Trigger + Flow recursion (the “infinite hallway”)
Sometimes you didn’t put a query in a loop. In fact, you built a system that loops.
Example pattern:
- Trigger runs on update
- Trigger updates a field
- Record-triggered Flow fires on that field update
- Flow updates the same record (or related records)
- Trigger runs again
- Congratulations, you’ve invented a query multiplier
Salesforce Stack Exchange calls this out constantly because it’s sneaky and common.
Step-by-Step Checklist: How to Fix It Without Guessing
1) Reproduce the error on purpose
Capture:
- The object and operation (insert/update/delete)
- The entry point (UI save, API integration, Flow interview, data load, Apex job)
- The record volume (single record vs bulk vs batch)
If it only fails “sometimes,” that’s usually a scaling clue: fan-out is volume-dependent.
2) Identify where the queries are coming from
In Apex, use debug logs to find:
- which trigger/class is consuming queries
- how quickly the query count grows
In Flow-heavy orgs, check:
- record-triggered flows on the object
- subflows invoked
- any “Get Records” inside loops
Your goal is simple: name the components that are spending queries.
3) Find the loop, the fan-out, or the recursion
You’re looking for one of three shapes:
- Loop query: query executed per record
- Fan-out query: one save triggers many automations that each query
- Recursion: the same automations re-trigger themselves
If you can’t draw the chain on a whiteboard, that’s not a personal failing. That’s a metadata visibility problem.
4) Refactor patterns that actually work
Pattern A: Query once, then map it
- Query related records in a single SOQL (outside loops)
- Store results in a Map<Id, List<SObject>> (or equivalent)
- Use the map inside the loop without additional queries
Pattern B: Consolidate logic
If you have 5 automations each doing “just a little query,” you still end up with 101. Consolidate where possible (especially duplicate lookups and repeated “does this record have X?” checks).
Pattern C: Break recursion explicitly
- Add a recursion guard (Apex static boolean patterns)
- In Flow, prevent re-entry via:
- entry conditions (only run when field changes to a specific value)
- a “processed” flag (last resort, but practical)
- moving work to before-save paths where appropriate (fewer side effects)
5) Retest like you mean it
Test for:
- single record save
- bulk updates (data loader / integration-style)
- worst-case paths (the record types/stages/branches that trigger the most automation)
If you only test the “happy path,” 101 will keep finding you in production.
Prevention: How to Stop Reintroducing 101 Every Quarter
“Too many SOQL queries” is usually the tax you pay when nobody can answer:
- What runs when this field changes?
- What else depends on this object?
- Which automation is doing lookups—Apex, Flow, managed package, or all three?
Prevention looks like:
- fewer duplicate automations
- consistent patterns (bulk-safe by default)
- change reviews that include dependency impact, not just “does it compile”
How Sweep Helps You Prevent Query Explosions
Governor-limit errors are rarely solved by heroics. They’re solved by context.
With Sweep, teams can:
- See automation + metadata dependencies in one place (so you can actually find the fan-out)
- Keep documentation live (so “why does this trigger exist?” doesn’t require Slack archaeology)
- Track changes over time (so you can correlate “this started last Tuesday” with “we deployed last Tuesday”)
That’s the difference between fixing a 101 today and preventing the next one.
In the End, Don’t Just Fix the Error—Fix the System
Too many SOQL queries: 101 is Salesforce telling you:
“Your system logic is doing more work than you think.”
Bulkify the code. Fix the Flow loops. Kill recursion.
But also: make sure your org’s logic lineage is visible enough that you can predict failures before production does it for you.
Having other troubles? Check out our Complete Guide to Agentforce Errors here.
