Get Records Inside a Loop: The Governor Limit Speedrun
“Put a Get Records element inside a loop. Hit 100 SOQL queries on the 101st record.”
What Happened
I needed to look up the Account for each Contact in a collection. Dragged a Get Records element inside the loop like a civilized person. Worked great in my sandbox with 15 test records. First bulk data load in production? 101 Contacts. Instant governor limit exception. The client's import failed halfway through and left orphaned records everywhere.
The Wrong Way
// Flow: Loop through Contacts collection
// For Each: {!currentContact}
// → Get Records: Account
// WHERE Id = {!currentContact.AccountId}
// → Update Records: {!currentContact}
//
// This executes 1 SOQL query PER loop iteration.
// At 101 records, you hit the 100 SOQL limit. Dead.The Right Way
// Flow: BEFORE the loop
// → Get Records: ALL Accounts where Id IN
// (use a formula or assignment to build the filter)
// → Store in {!allAccounts} collection
//
// Inside the loop:
// → Use a Decision element or Assignment
// to match from the pre-fetched collection
//
// Or better: use a Before-Save flow and access
// {!$Record.Account.Name} directly via dot notation
// — zero SOQL queries needed.The Lesson
Never put Get Records inside a loop. Fetch everything you need BEFORE the loop starts. This is the #1 Flow performance mistake and I still see senior admins doing it.
Enjoyed this? Get more like it.
Glen's Musings — AI, investing, and building things. Occasional. Free.
More Flows Mistakes
The Infinite Flow Loop That Ate Production
Record-triggered flow updates the same object. Flow fires again. And again. And again.
Read moreAnnoyingThe Flow With No Fault Path (Enjoy Your Cryptic Error)
Deployed a screen flow with no fault handling. Users got 'An unhandled fault has occurred' and I got 50 support tickets.
Read morePainfulHardcoded Record IDs in Flows: The Sandbox Surprise
Hardcoded a Record Type ID in a flow. Deployed to production. Different ID. Everything broke.
Read more