Okta Certified Workflows - Specialty · Part I

Workflows Overview

27% of Part I — the exam's largest single knowledge area alongside Building Flows.

Workflows Overview

Sub-topic 6: Understand Execution Limits

7 sub-topics · this deck covers sub-topic 6 of 7

The Task

"Okta Workflows operates on a multi-tenant system... some flows become eligible for the internal system limit analyzer to determine if a flow requires throttling."

This is the most numbers-dense sub-topic in the module. The exam expects you to know the four throttling resources, what flow throttling actually does (and doesn't do), the Green/Yellow/Red use-case zones, low-latency mode, and data streaming — with real limit numbers.

Flow Throttling — The Four Resources

Resource	What triggers it
CPU time	Milliseconds executing on engine worker threads; nested iteration cards (For Each, Map, Reduce) can grow executions exponentially
Table requests	Requests against a Workflows table via Tables function cards
Memory	Bytes held in memory; flows reading large user sets
Helper flows	Number of invoked helper flows; deep/recursive helper structures

"Flow throttling doesn't impact or prevent the completion of a flow" — it limits resource allocation, but the flow still finishes. Free Trial and Workflows Starter plans are subject to a lower throttling threshold than paid plans.

Green / Yellow / Red Zones

Green (well-supported): documented core use cases, scheduled/async flows, event-driven provisioning, data-streamed inbound reads. Yellow (needs careful architecture, best-effort support): event hooks above 100,000/day, non-streamed bulk searches, synchronous auth-decision flows, low-latency-requirement flows, 3-60 second latency flows, one-time bulk imports, raw HTTP integrations, API-Endpoint-first flows. Red (unsupported): continuous directory sync / HRaaS-style architectures, on-premises app connections.

Key Platform Numbers — Flows & Executions

Limit	Value
Active flows per org	Free Trial/Starter: 5 · Light: 50 · Medium: 150 · Maximum: unlimited (legacy entitlements: 100 parent flows)
Memory per Workflows instance	100 MB
Maximum pause duration	30 days
Maximum steps per flow	2,000,000
Rate limit, direct API flow invocation	10 invocations/second/flow (429 if exceeded)
Helper flow recursion limit	250 ("Stack limit exceeded" error beyond this)
Payload/message size stored in history	1 MB (larger payloads succeed but aren't displayed)

Key Platform Numbers — API, Hooks & Automations

Limit	Value
Synchronous API endpoint timeout	60 seconds
Asynchronous action timeout	120 seconds
Event/inline hook completion timeout	3 seconds, one retry (not retried on 4xx)
Daily event hook events per org	400,000 (System Log warns at 280,000)
Event hooks per org	25 max, up to 100 events per payload
Flows using an Okta event card as trigger	500 max per org
Inline hooks per org	100 max (combined across types)
Automations per org	50 max · 10 groups/automation · 1,000,000 users/automation

Low-Latency Mode

Low-latency mode routes eligible flows into a dedicated queue with minimal wait time, so large or throttled flows don't delay them. Flows that always start in low-latency mode: those beginning with an API Endpoint card, an Okta connector event card, a third-party webhook connector card, or a Delegated Flow event card.

A flow is removed from low-latency mode if it hits: excess resource usage, a third-party 429 rate-limit error, an explicit pause (Wait For / Wait Until / Pause), a timeout past 60 seconds, a data-streaming action, an async call (Call Flow Async), or use of the HTTP Close card.

Data Streaming

Search/list results are normally capped at 10,000 records. The Stream Matching Records option lets an action card hand large result sets off to a helper flow, using pagination-enabled endpoints — scaling up to 1 million records. Benchmarks: 500,000 records ≈ 13 hours; 1 million records ≈ 25 hours. A streaming flow can't be stopped once execution begins, and an in-progress stream keeps running even if you deactivate the flow.

The Gotcha — Limits That Look Alike but Aren't

Don't conflate the synchronous API timeout (60 seconds) with the low-latency timeout constraint (also 60 seconds) — they're the same number by coincidence, but one governs whether the caller's HTTP connection stays open, the other governs whether the flow stays in the fast queue. Also: exceeding the helper flow recursion limit (250) throws a distinct "Stack limit exceeded" error, separate from throttling warnings.

The Connection

This sub-topic operationalizes Sub-topic 1's "supported use cases" boundary with hard numbers, and it directly explains why Sub-topic 5's client-token/public-service flows are Yellow Zone by default (external, potentially high-frequency callers). It's also the natural bridge into Part I's next section, Architecting Flows, where these limits shape upfront flow design decisions.

The Angle — What Trips People Up

→ Assuming throttling stops a flow — it doesn't; the flow completes, just with reduced resource allocation and a warning dialog.

→ Forgetting event hook delivery order isn't guaranteed — concurrent events for the same user can be processed out of order (Okta's own deactivate/reactivate race-condition example).

→ Missing that a Wait For/Wait Until/Pause card silently disqualifies a flow from low-latency mode, even if everything else about the flow qualifies.

One Line To Remember

Flow throttling (CPU, table requests, memory, helper-flow count) never stops a flow, just slows it; low-latency mode auto-applies to API Endpoint, Okta-event, webhook, and Delegated flows but is broken by pauses, timeouts (60s), rate limits, or streaming; and data streaming scales searches to 1 million records at roughly 25 hours.

Sources: help.okta.com — Execution limits (ext-execution-limits); Workflows system limits; Low-latency mode; Criteria for low-latency mode; Stream data with action cards

Next: Sub-topic 7 →