Workflows system limits
There are Workflows system limits that can impact the design and success of your Flow.
General guidelines
Okta Workflows is a powerful and flexible platform, but it is designed, tested, and optimized for specific use cases and architectures. This section includes information on system limits that can impact the success and performance of your Flows.
| Green Zone | Yellow Zone | Red Zone |
|
These use cases are well tested and supported:
Workflows is well-suited for such operations. |
These use cases require monitoring, attention to architecture, and awareness of system limits:
It is recommended to work with Okta's services team to ensure success. |
These use cases are not currently supported, and not compatible with lifecycle management Workflows:
|
Workflows platform limits
| Category | Title | Limit | Description |
| Flows | Number of active Flows per OrgThe Okta container that represents a real-world organization. | 50 |
Only 50 Flows can be turned on in an org simultaneously. The Flow limit does not include child flows. Flows that are turned off are not counted against the limit. The limit is configurable on a per-org basis. |
| Flow Executions |
Workflows instance memory limit |
100MB |
Limit on the instance variables that are stored in a Flow as part of its execution. |
|
Maximum pause duration |
30 days |
The amount of time that a Flow can be paused as it waits for a person's or a system's response before it terminates. |
|
|
Maximum steps per flow |
2M |
The maximum number of steps that can be executed in a Flow. |
|
| Rate limit for Flow executions | 10 invocations per second per Flow |
There are different limits for event and inline hook delivery (see below). However, if you're invoking a Flow directly from the API, there's a limit of 10 invocations per second per Flow. Once that limit is exceeded, a 429 response code will occur. |
|
| Flow History | Data time to live | 30 days | The time limit on Flow Execution history that appears in the Workflows Designer console. |
|
Flow Tables |
Number of tables |
100 |
The number of tables available in an org. This limit is configurable on a per-org basis. |
|
Row limits |
100K |
The maximum number of rows in a table. You cannot add a row to a table after you've reached the limit. |
|
|
Column limits |
256 |
The maximum number of columns in a table. You cannot add a column to a table after you've reached the limit. |
|
|
Cell limits |
16kb |
The size limit of a single Workflows table. |
|
|
API |
Timeout |
60 seconds |
An incoming HTTP connection to an API endpoint that invokes a synchronous Flow will only wait this long before terminating the connection. However, the Flow itself will not be terminated. |
|
API Endpoints |
Callable Workflows API endpoints |
100MB total, 25MB per part |
The limit for multipart files. |
Hooks
There are limits on Okta Event and Inline Hooks that are used to trigger Flows.
Neither Event Hook delivery nor Flow execution order is guaranteed. It is a fully asynchronous environment. It is important to consider that concurrent events could be fired for a single user, and the state of a user may have changed since the event was fired. For example, a user may have been deactivated accidentally and then immediately reactivated. A Flow that responds to the deactivation event may run either before or after the reactivation event. Similarly, the user may not be deactivated anymore by the time the deactivation Flow runs.
There are some more complex considerations. In exceptional cases, like an infrastructure failover, Okta may process some requests in a read only mode until the failover is complete. That means that an event may fire for a process that cannot complete. The best example is one that is not currently supported by the Workflow product: Password Import Inline Hook. It is possible for that hook to fire, but the user is not imported because of the read-only mode. Listeners shouldn’t delete the user from a legacy system until they see the user creation event and not assume that the hook firing was sufficient.
| Feature | Limit Type | Limit | Description |
| Event Hooks | Number of daily event hooks | 100K |
A max of 100K event hooks can be fired per org per day. Event hooks are not recorded or replayed after this point. Outside of hitting the daily limit, Workflows event hooks are retried up to a certain time limit. |
|
Inline Hooks |
Timeout |
3 seconds |
Okta Inline Hooks have a completion timeout of three seconds with a single retry. A request is not retried if your endpoint returns a 4xx HTTP error code. Any 2xx code is considered successful, and thus the request is not retried. If the external service endpoint responds with a redirect, it is not followed. |
For additional guidelines, see Event Hooks and Inline Hooks.
Okta API
The Okta API has specific per-org rate limits that apply to all actions taken by Workflows. These rate limits vary by endpoint and pricing plan, but are shared between Workflows actions and actions from external apps. For more information, see Rate Limits.
If you have a custom integration using the Okta API and are also experimenting with new Workflows development, you can exceed your Okta rate limit and disrupt both activities. It is recommended to develop new Flows in a preview environment to avoid these issues. If disruptions do occur, pause any new Flow until the rate limit rests in the next minute.
Cell Support
Workflows is available for North America and EU production and preview cells.
Workflows is not currently available for Asia Pacific/Japan (APJ) or Compliance (HIPAA / FedRAMP cells.
Top