Number of iterations exceeded. The flow can't perform more than 2,000 loop iterations.
A Flow `Loop` element ran more than 2,000 iterations. The fix is to operate on the *collection* directly (Update Records, Get Records with filters, or assignment to a record collection) instead of iterating record-by-record.
Also seen asNumber of iterations exceeded·2,000 loop iterations·flow loop iteration limit·loop iterations exceeded flow
Flow's Loop element exists for cases where you genuinely need to process each record one at a time. The 2,000-iteration cap exists because most uses of Loop are unnecessary — Flow has bulk operations that do the same work without iteration.
Why this fires
You have a Get Records that returns a collection, and a Loop that goes through each record. Common shape:
Get Records: All Open Cases on this Account
→ Loop over each Case
→ Assignment: set Status = "Reviewed"
→ Update Records: 1 case
If the Account has more than 2,000 open Cases, the loop fails. But also: this design is inefficient even at 100 cases — it does 100 individual Update Records calls instead of one bulk one.
The fix: operate on the collection
Replace the loop + per-record update with a single bulk update.
Get Records: All Open Cases on this Account → {!cases}
→ Update Records: Update {!cases} with Status = "Reviewed"
Update Records accepts a collection variable directly. One DML, all records, no loop.
If you need to filter the collection before updating, use a Collection Filter element (Spring '23+) or build a sub-collection by assignment. Both avoid the loop.
When you really do need a loop
Some flow logic is genuinely per-record:
- Sending a different email to each user based on per-record data
- Calling an Apex action that processes one record at a time
- Building a complex string by accumulating across records
For those, the 2,000 cap is a hard ceiling. Workarounds:
- Use Batch Apex instead of Flow — async, chunked, no 2,000 cap.
- Use a Schedule-Triggered Flow that processes 200 records at a time, scheduled hourly. The whole org gets processed in chunks without any single execution hitting the cap.
- Use a Platform Event with a Subscriber Apex Trigger — fire one event per record, the subscriber processes them async.
A subtler cause: loops within loops
A loop iterating parents that contains a loop iterating children is parents.length × children.length iterations total. With 50 parents × 50 children, you're at 2,500 — just over the cap. Fix: precompute a Map<Parent_Id, List<Children>> (use the Get Records + Filter Collection pattern) so the inner traversal is O(1) lookups instead of nested loops.
How to count iterations as you debug
Open the flow in Debug mode. The right-hand panel shows each element's invocation count and any variables in scope. If a loop element shows >2,000 iterations, you've found the culprit. If it shows fewer but you're still hitting the limit, look for nested loops elsewhere.
A Process Builder migration tip
If this flow was migrated from Process Builder, the conversion sometimes generates loops that didn't exist in the original. Process Builder's "Update Records" already handled bulk; the migration may have wrapped it in a loop unnecessarily. Re-check after migration and replace loops with bulk updates.
