Limit error in Get Records when using IN operator in record-triggered Flow

Posted by Vinay Vernekar 2nd December 2025

A common Flow pitfall: using the IN operator with an empty text collection can return all records and trigger governor limit errors. Learn how to detect and prevent it in record-triggered Flows.

Problem summary

When a Record-Triggered Flow uses a Get Records element with the IN operator and the text collection variable used for the IN is empty, Salesforce can evaluate the query as if no filter was present and return all records for that object. That unexpected query counts toward the org’s query rows and can throw limit errors (for example, when total rows exceed 50,000).

Why this happens

The Flow engine evaluates the IN clause even when the collection is empty in some cases. Instead of returning zero rows, the underlying evaluation can produce a broad query that matches many records. Those returned rows are counted against the governor limits, causing the flow to fail in large orgs.

How to reproduce

  • Create a record-triggered flow that runs on the desired object (for example, Account).
  • Set up a text collection variable (e.g., varIds) and use it in a Get Records element with the condition Account.Id IN {!varIds}.
  • Trigger the flow when varIds is empty. Observe that the Get Records returns a non-zero number of rows and may hit limits in large orgs.

Fix / Best practice

Always guard Get Records queries that use collection-based operators (IN) with an explicit check to ensure the collection is not empty. In Flows you can use a Decision element, or an Assignment + Decision, to skip the Get Records when the collection is empty.

  • Before the Get Records element, add a Decision element named Has IDs.
  • Set the outcome to check the collection is not empty. Example condition: Is Empty {!varIds} = False (or use the Flow operators to check length > 0).
  • If the collection is not empty, proceed to the Get Records using IN. If it is empty, skip the Get Records branch or handle the empty case explicitly.

Example Flow logic

Decision: Has IDs
- Outcome: Yes — {!varIds} Is Empty = False
- Outcome: No — Skip Get Records

Get Records (only on Yes outcome)
- Object: Account
- Condition: Id IN {!varIds}

Additional recommendations

  • Use descriptive Decision/Outcome names so future maintainers understand why the check exists.
  • Log or monitor flow failures after deployment so you can quickly detect unexpected behavior caused by empty collections.
  • For very large datasets, consider batching processes outside of a synchronous record-triggered flow.

Conclusion: why this matters

For Salesforce admins and developers, this is a small defensive change that prevents a surprising and potentially high-impact governor limit failure. Guarding Get Records queries that rely on collections keeps Flows predictable and scalable — especially in production orgs with large data volumes.

Categories: Salesforce Tips

Tags: