13% of Part I
4 sub-topics · this deck covers sub-topic 4 of 4
↑ Module OverviewOkta groups flow design guidance into supported use cases and hard platform limits. Use cases fall into a Green Zone (well-tested), Yellow Zone (higher risk of hitting a limit — includes flows starting with the API Endpoint card, and anything with low-latency requirements), and Red Zone (unsupported, e.g. continuous directory sync or on-prem connections).
Flow Tables have their own hard caps:
Row limit: 500,000 rows per table — you can't add a row once you hit it. Column limit: 64 columns — you can't add a column past it.
Cell limit: 16 KB per cell (updating past this returns an error), with a separate 16,000-character limit per cell. Table count: 200 tables on a paid tier, 100 tables on the free tier.
Invoking a flow directly from the API (as in the previous sub-topic) is capped at 10 invocations per second per flow. Exceeding it returns a 429 error code.
Separately, the built-in Okta connector has its own concurrency caps against your Okta org: 30 concurrent requests total, 15 concurrent GET/READ requests to /api/v1/users/${id} (doesn't count against the 30), and 6,000 total requests per minute. These don't appear in the standard rate-limits dashboard. A DynamicScale add-on or the post-Jan-7-2021 workforce multiplier can raise these tiers (e.g. up to 150 concurrent requests at the 50x tier).
Event hooks: 3-second completion timeout with one retry; 400,000 applicable events per org per 24 hours (a System Log warning fires at 280,000); max 25 active event hooks per org; max 500 flows triggered by an Okta event card; max 100 events grouped per event hook payload.
Inline hooks: same 3-second timeout/1-retry behavior; max 100 inline hooks per org, combined across all inline hook types.
Flows with strict low-latency requirements (including inline hooks) sit in the Yellow Zone — system load can push latency 10 times higher than average. The API Endpoint's synchronous timeout is 60 seconds; the asynchronous wait timeout is 120 seconds.
Other execution limits: 100 MB instance memory per flow execution, 30-day maximum pause duration, 2 million maximum steps per flow, a 250-call recursion limit for a helper flow calling itself (past it: "Stack limit exceeded"), and a 1 MB payload limit per message (oversized entries are replaced with a "too large to display" notice, with no impact on flow success).
The number of active flows an org can run depends on the Workflows plan: Free Trial and Starter — 5 active flows; Light — 50; Medium — 150; Maximum — unlimited. Flows that are turned off don't count against this limit (tying directly back to the ON/OFF toggle from Sub-topic 1). A legacy Advanced Lifecycle Management entitlement caps active parent flows at 100.
Because API Endpoint flows are timeout-sensitive, Okta recommends: structure the flow asynchronously so the caller doesn't wait; place the API Connector Close card first to release the HTTP connection immediately while the rest of the flow processes; for synchronous responses, avoid external network calls in the synchronous path (offload them to a helper flow via Call Flow Async) and return the response as soon as it's ready.
For the engine generally: split large jobs into helper flows with Call Flow Async or For Each - Ignore Errors; limit nested If Error blocks to no more than three; use Filter instead of stopping a helper flow early; pass only the fields a helper flow needs rather than a whole object; and prefer streaming actions (Stream Matching Records) over non-streaming result sets to keep memory use low.
Every number on this deck maps back to a mechanism from earlier in the section: the active-flow-per-plan limit only counts flows turned ON (Sub-topic 1); the 10-invocations-per-second and timeout limits apply directly to the API Endpoint flow (Sub-topic 2); and the throttled-mode / low-latency icons in Execution History (Sub-topic 3) are the visible symptom of hitting these same resource and rate limits.
Watch for this in your own sandbox run:
→ Confusing the flow-invocation rate limit (10/sec per flow, returns 429) with the Okta connector's org-level limits (30 concurrent, 6,000/min) — they're separate caps that apply in different places.
→ Assuming a throttled flow instantly returns to low-latency eligibility once load drops — it stays in throttled mode for a fixed 15 minutes regardless.
Sources: help.okta.com — ext-workflows-system-limits (Workflows system limits), ext-best-practices-building (Best practices for building flows)