Flow: "Too many query rows: 50001" error in Get Records or lookup elements

Follow the steps below in order. Steps 1–3 identify which element consumes the rows; the remaining sections fix the most common causes.

1. Open Setup > Process Automation > Flows and open the failing flow in Flow Builder.
2. From Setup > Environments > Logs > Debug Logs, add a trace flag for the affected user, then have the user reproduce the failure. Open the resulting log and search for "SOQL_EXECUTE_BEGIN" and "FLOW_ELEMENT_BEGIN" entries. The cumulative "Number of SOQL queries" and "Number of query rows" counters identify the element that crosses 50,000.
3. In the debug log, also check whether the same transaction fires Apex triggers or managed-package triggers (for example FinServ.LeadTrigger). If a managed-package trigger consumes most of the 50,000 rows before your flow runs, the fix belongs in the package configuration, not in the flow.

Cause 1: Get Records element inside a Loop
1. In Flow Builder, locate any Get Records [recordLookups] element placed between a Loop [loops] start and end.
2. Move the Get Records element outside the Loop so it executes once. Query all required records up front into a collection variable, then iterate the collection inside the Loop.
3. If you must filter per iteration, build a collection of the loop keys before the Loop and use a single Get Records with the "In" operator against that collection.

Cause 2: Get Records with no filter or filters that are too broad
1. Open the failing Get Records element.
2. Under Filter Records, set "Condition Requirements" to "All Conditions Are Met (AND)".
3. Add concrete filters that restrict the result set — for example, on Lead [Lead] add Status [Status] Not Equal To Closed, and OwnerId [OwnerId] Equals {!$User.Id}.
4. Under "How Many Records to Store", select "Only the first record" when a single match is sufficient.
5. Under "How to Store Record Data", select "Choose fields and assign variables" and select only the fields the flow actually uses. This does not lower the row count but reduces heap and reveals over-broad queries during testing.

Cause 3: Get Records uses the "In" operator with a possibly empty collection (Known Issue KI-17138)
1. This is tracked as Known Issue KI-17138: a Get Records "In" condition with an empty collection consumes FLOW_ELEMENT SOQL_ROWS limit usage.
2. Before the Get Records element, add a Decision [decisions] element with an outcome "Collection Has Items" using the condition {!yourCollection} Is Null = False AND {!yourCollection} (count) Greater Than 0.
3. Route the "Collection Has Items" path into the Get Records element. Route the default path around it.

Cause 4: A managed-package or Apex trigger consumes the budget (for example FinServ.LeadTrigger, cgcloud__Order__Share)
1. Identify the trigger from the error prefix in the message — "FinServ.LeadTrigger:" indicates the Financial Services Cloud Lead trigger; "cgcloud__" indicates Consumer Goods Cloud.
2. Reduce the volume of related records the trigger queries. For Financial Services Cloud, review duplicate or unmerged Lead, Account, and Contact records owned by or shared with the affected user and merge or reassign them so the trigger's internal queries return fewer rows.
3. For Consumer Goods Cloud, avoid Get Records queries against sharing tables (cgcloud__Order__Share, cgcloud__Visit__Share) inside loops; query the parent object and rely on sharing implicitly.
4. If the managed-package trigger itself exceeds 50,000 rows on a single record edit and no record-volume reduction is possible, log a Salesforce Support case and request managed-package debug logs.

Cause 5: One specific user fails while others succeed
1. The failing user typically owns or is shared on more records than other users, so their transaction crosses 50,000 rows while others stay below it.
2. Inspect the user's record ownership for the queried object (for example, Lead [Lead] or your custom support-request object). Reassign or archive records to bring the user's footprint in line with peers.
3. Re-test as that user. If the per-user record count cannot be reduced, apply Causes 1–3 to lower the flow's per-transaction row consumption.

Confirm the issue is resolved by reproducing the original action — for the affected user, perform the create or update on the source record (Lead, Contact, or the custom support-request object) that previously failed, and verify the flow completes without the "Too many query rows: 50001" error and the record saves successfully.