The quick version: when a Get Records element finds nothing, the variable is set to null, not to an empty collection. Test it with Is Null equals True in a Decision before anything downstream touches it. And turn off “Automatically store all fields” on any Get Records that can return more than a handful of rows, because that setting pulls back every field the running user can see.
The four settings that decide what comes back
The filter, the sort, and the record count become a SOQL query the platform runs for you. The storage choice decides which columns that query selects.
- Filter conditions become the WHERE clause, with All Conditions, Any Condition, or custom logic such as
1 AND (2 OR 3). - Sort becomes ORDER BY, on one field, ascending or descending.
- How Many Records to Store is either the first record or all records. There is no “first ten”.
- How to Store Record Data is automatic, chosen fields, or manual assignment into separate variables.
Zero results is null, and that is not a detail
With “Only the first record” selected, a query that matches nothing leaves the record variable null. The next element that references {!Get_Account.Name} ends the interview with an error naming that element and the null value. Users see “An unhandled fault has occurred in this flow”.
With “All records” it is worse, because it is quiet. A Loop over a null collection does not error and does not iterate. The flow finishes, reports success, and does nothing. If a flow appears to skip records for some users and not others, check this first.
The guard is one Decision with the outcome {!Get_Contacts} Is Null True. Do not test a field on the record to work out whether the record exists, because that reference is exactly what throws — the error you get is Attempt to de-reference a null object, and an empty Get Records is where most of them start.
First record versus all records
Pick “Only the first record” when the filter genuinely identifies one row: a record Id, a unique external Id, a Custom Metadata developer name. Anything looser and you are relying on whichever row the database handed back first, which is not guaranteed to stay stable between runs.
So if you store the first record, set a sort as well. Sorting by CreatedDate descending turns “some record” into “a specific record”.
Sorting happens in the query, not in the flow
The sort takes a single field. You cannot sort by Account and then by Amount in one Get Records. That needs a Collection Sort element afterwards. And because SOQL is doing the ordering, ascending puts empty values at the top. A sort on a mostly-blank date field ascending gives you a page of blanks before anything useful. Sort descending, or exclude the blanks in the filter.
All fields is the wrong default
“Automatically store all fields” is convenient at build time, since every field is available downstream without you predicting which ones you need. The cost is a query selecting every accessible field on the object, for every row returned, on objects that often carry hundreds of fields. Heap in a synchronous transaction is 6 MB.
Choose “Choose fields and let Salesforce do the rest” and select only what later elements reference. Narrower query, smaller heap, and something useful at review time: the element now documents which fields this flow depends on. With automatic storage that dependency is invisible until someone deletes a field and the flow breaks.
Filter in the query, never in a loop
Getting every Contact on the Account and then filtering inside a Loop is the most common performance mistake in Flow. The query returns rows you throw away, and each iteration burns executed elements against the 2,000 per interview limit. Push the test into the filter conditions where the database can use an index.
Frequently asked
Does each Get Records count as a SOQL query? Yes, one per execution. Put one inside a Loop and you get one per iteration, which is how flows hit the 100-query limit on a 200-record data load.
How do I count how many records came back? There is no count operator on a collection in a Decision. Increment a Number variable inside a Loop, or test Is Null and treat non-null as “at least one” when that is all you need.
Why does my flow return a record the user should not see? The flow is running in system context. Check “How to Run the Flow” on the Start element and use System Context With Sharing unless you have a reason not to.
Can I limit the number of rows returned? Not in the element. Get all records, then use a Collection Sort with its record limit to keep the top few.
