43% of Part I — the exam's largest section, split across 4 modules.
this deck covers 1 of 4 sub-topics in this module
↑ Module 3 OverviewA flow needs to process a data set that's far too large to handle normally — well beyond the 10,000-record ceiling on ordinary search results. This is the mechanism the exam expects you to reach for.
The Stream Matching Records option appears on many action cards that have search or list options — for example, Freshservice Search Tickets or Okta List Users with Filter. Instead of processing the data set inside the parent flow, you point the card at a helper flow (via the Choose Flow dialog) that's built to handle many records. Using pagination-enabled API endpoints and a helper flow, a flow can process up to 1 million records.
Even where search-result limits are respected, wide records — many custom user properties or heavy user data — can still push a flow past system limits and trigger out-of-memory errors. Streaming shunts that processing load off into a dedicated helper flow so the parent flow doesn't choke on it.
These are real published benchmarks, not estimates — expect the exam to test whether you know streaming is for genuinely large jobs, not a casual default.
Watch for this in your own sandbox run:
→ Assuming you can stop a streaming flow mid-run. You can't — once execution begins, a helper flow that streams data runs until the API returns all records or the flow hits its specified maximum. An in-progress flow doesn't even stop if you deactivate the flow.
→ Forgetting the hard ceiling: the maximum limit of returned records is 1 million, and processing halts when it reaches the page limit you (or the connector) specify.
Source: help.okta.com — Stream data with action cards (ext-about-streaming)
Next: Boolean Logic & Operators →