Screen Flow Client Payload Limit: Optimizing Large Record Lookups
Screen Flows have a rarely documented constraint that can cause cryptic failures when querying large record sets: a client-side payload limit of approximately 6MB. When the data returned by a Get Records element exceeds this threshold, the Flow fails with an unhelpful error message, leaving developers searching for a governor limit that does not appear in any standard documentation.
The Root Cause
By default, when you configure a Get Records element in Flow Builder and choose "Automatically store all fields," the metadata sets storeOutputAutomatically to true. This instructs Salesforce to retrieve and serialize every field on the queried object, regardless of how many fields the Flow actually uses.
For objects with 50-100+ fields, each record can weigh approximately 2-3KB when serialized. Querying 300 or more records at this density can push the total payload well past the 6MB client limit. The critical distinction here is that this is a client-side limit, not a server-side SOQL governor limit. The query itself succeeds, but the serialized payload cannot be transmitted to the Screen Flow's client runtime.
Symptoms
- The Flow works in testing with small data sets (10-50 records) but fails in production with larger volumes.
- The error message is vague, often referencing an "unhandled fault" or a generic system error.
- Debug logs show the SOQL query completing successfully with records returned.
- Reducing the number of records queried (via tighter filter criteria) makes the error disappear.
The Fix: Explicit queriedFields
Instead of storing all fields automatically, specify only the fields your Flow actually needs. In the Flow metadata XML, this means replacing storeOutputAutomatically with an explicit list of queriedFields.
Before: All Fields (Problematic)
<recordLookups>
<name>Get_Order_Items</name>
<label>Get Order Items</label>
<object>OrderItem</object>
<storeOutputAutomatically>true</storeOutputAutomatically>
<getFirstRecordOnly>false</getFirstRecordOnly>
<filterLogic>and</filterLogic>
<filters>
<field>OrderId</field>
<operator>EqualTo</operator>
<value>
<elementReference>recordId</elementReference>
</value>
</filters>
</recordLookups>
After: Explicit Fields (Optimized)
<recordLookups>
<name>Get_Order_Items</name>
<label>Get Order Items</label>
<object>OrderItem</object>
<storeOutputAutomatically>false</storeOutputAutomatically>
<getFirstRecordOnly>false</getFirstRecordOnly>
<outputReference>orderItemCollection</outputReference>
<queriedFields>Id</queriedFields>
<queriedFields>Product2Id</queriedFields>
<queriedFields>Quantity</queriedFields>
<queriedFields>UnitPrice</queriedFields>
<queriedFields>Description</queriedFields>
<filterLogic>and</filterLogic>
<filters>
<field>OrderId</field>
<operator>EqualTo</operator>
<value>
<elementReference>recordId</elementReference>
</value>
</filters>
</recordLookups>
By specifying only the 5 fields needed instead of all 80+ fields on the object, the per-record payload drops from roughly 2.5KB to under 250 bytes. This represents a 10x or greater reduction in total payload size, comfortably fitting hundreds of records within the client limit.
Setting queriedFields in Flow Builder
In Flow Builder, you can achieve this through the UI:
- Open the Get Records element.
- Under "How to Store Record Data," select Choose fields and assign variables (advanced).
- Select only the fields your Flow references downstream.
- Store the results in a record collection variable.
This approach requires you to define a record collection variable of the appropriate SObject type, but the performance benefit is substantial.
General Guidelines for Screen Flow Record Limits
| Record Count | All Fields (~2.5KB each) | 5 Fields (~250B each) |
|---|---|---|
| 100 | ~250KB | ~25KB |
| 500 | ~1.25MB | ~125KB |
| 2,000 | ~5MB | ~500KB |
| 3,000 | ~7.5MB (fails) | ~750KB |
Best practices:
- Always specify explicit fields in Get Records elements for Screen Flows.
- If you must display large record sets, implement pagination or filtering to limit the visible records.
- Record-Triggered Flows and Autolaunched Flows are less affected because they run server-side without the client payload constraint.
- Test with production-scale data volumes, not just sandbox samples.
Key Takeaway
The ~6MB client payload limit is an architectural constraint of Screen Flows, not a configurable setting. The fix is straightforward: never use storeOutputAutomatically when querying objects with many fields or when record volumes could exceed a few hundred rows. Specifying explicit queriedFields is a low-effort change that eliminates the problem entirely.