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.