Workflows system limits

There are Workflows best practices and system limits that can impact the design and success of your flow.

Guidance for Workflows scale and performance
Supported use cases
Workflows platform limits
Latency
Hooks
Automations
Okta API
Cell Support

Guidance for Workflows scale and performance

Okta Workflows is a powerful and flexible platform for automating identity processes. It is designed, tested, and optimized for a growing set of lifecycle management, data synchronization, and task automation use cases, and can be extended to do much more.

In this section, read about common use cases, important principles and limits to keep in mind when building flows, and how to ensure successful deployments.

As a Workflows customer, you will be more successful when you perform these tasks:

Understand supported use cases. See Supported use cases.
Build flows using best practices and strong architecture. See Best practices for building flows.
Understand the system's hard limits. See Workflows platform limits.

Supported use cases

While Workflows can do many things, it is optimized for a specific set of identity related tasks. These are documented in both our help center and within Workflows using a variety of resources.

Use cases	Templates	Connectors
Workflows is optimized and tested for a set of core workforce identity and customer identity use cases. See Okta Workflows use cases.	Okta develops and curates an expanding library of importable templates. These are reviewed by Okta before they are released. See Available Workflows Templates.	Okta maintains a large set of native SaaS connectors that include easy API connectivity, improved usability and documentation, and optimizations such as built-in backoff and retry. See Connectors.

Use cases

Templates

Connectors

Workflows is optimized and tested for a set of core workforce identity and customer identity use cases.

See Okta Workflows use cases.

Okta develops and curates an expanding library of importable templates. These are reviewed by Okta before they are released.

See Available Workflows Templates.

Okta maintains a large set of native SaaS connectors that include easy API connectivity, improved usability and documentation, and optimizations such as built-in backoff and retry.

See Connectors.

Use cases can be classified approximately within zones.

Green Zone	Yellow Zone	Red Zone
These use cases are well tested and supported: Documented Okta core use cases for workforce and customer identity. See Okta Workflows use cases. Scheduled flows and asynchronous use cases without specific latency requirements. Event-driven provisioning or other interfacing between Okta and third-party SaaS systems, including event hooks. Inbound data reading with Okta search, get, or list cards using data streaming from Okta or third-party systems. See Set up the stream matching option with a helper flow.	These use cases require careful attention to architecture and best practices, and have a higher risk of running into system limits or other caveats. Support is best effort and working with professional services is recommended to ensure success. Okta event hook flows above 100,000 events per day. Moderate scale bulk data searches or listing from Okta or third-party systems that do not use data streaming (see About data streaming with action cards). Flows with moderate latency requirements of 3 to 60 seconds, with understanding that at times executions may take longer than 60 seconds. One-time large directory imports, migrations, or bulk loads. Custom integrations to third-party systems using raw HTTP requests. Large data processing within a single execution. Flows that start with the API Endpoint card. Common challenges in this area include: System load may cause latency variance of 10 times or more than average performance. You may hit rate limits or timeouts with third-party systems. Large flows may be stopped due to excessive memory usage. The system may throttle flows due to excessive resource usage. See About execution limits.	These use cases are not currently supported: Synchronous flows such as customizing an auth decision or orchestrating user interaction. Flows with specific low-latency requirement, including inline hooks. See Latency. Continuous directory synchronization, such as implementing an HRaaS architecture using Workflows and raw user APIs. Flows for on-premises scenarios or support for connections to on-premises applications.

Green Zone

Yellow Zone

Red Zone

These use cases are well tested and supported:

Documented Okta core use cases for workforce and customer identity. See Okta Workflows use cases.
Scheduled flows and asynchronous use cases without specific latency requirements.
Event-driven provisioning or other interfacing between Okta and third-party SaaS systems, including event hooks.
Inbound data reading with Okta search, get, or list cards using data streaming from Okta or third-party systems. See Set up the stream matching option with a helper flow.

These use cases require careful attention to architecture and best practices, and have a higher risk of running into system limits or other caveats. Support is best effort and working with professional services is recommended to ensure success.

Okta event hook flows above 100,000 events per day.
Moderate scale bulk data searches or listing from Okta or third-party systems that do not use data streaming (see About data streaming with action cards).
Flows with moderate latency requirements of 3 to 60 seconds, with understanding that at times executions may take longer than 60 seconds.
One-time large directory imports, migrations, or bulk loads.
Custom integrations to third-party systems using raw HTTP requests.
Large data processing within a single execution.
Flows that start with the API Endpoint card.

Common challenges in this area include:

System load may cause latency variance of 10 times or more than average performance.
You may hit rate limits or timeouts with third-party systems.
Large flows may be stopped due to excessive memory usage.
The system may throttle flows due to excessive resource usage. See About execution limits.

These use cases are not currently supported:

Synchronous flows such as customizing an auth decision or orchestrating user interaction.
Flows with specific low-latency requirement, including inline hooks. See Latency.
Continuous directory synchronization, such as implementing an HRaaS architecture using Workflows and raw user APIs.
Flows for on-premises scenarios or support for connections to on-premises applications.

Workflows platform limits

Category	Title	Limit	Description
Flows	Number of active flows per Org	Varies per plan	An admin is allowed to run a maximum number of active flows according to these tiers: Workflows Starter: 5 active flows Light Workflows: 50 active flows Medium Workflows: 150 active flows Unlimited Workflows: Unlimited active flows Flows that are turned off are not counted against the limit. The limit is configurable on a per-org basis. See Flow limits. If you have a legacy Workflows entitlement (for example, from Advanced Lifecycle Management), then you are limited to 100 active parent flows.
Flows	Number of flows in an exported folder	Varies per plan	Using the Export Flow function card, the maximum number of flows that you can export is determined by your Workflows subscription plan. Your organization’s available export capacity is reset every 15 minutes. To perform a successful export, the number of exported flows cannot exceed the assigned limit. Otherwise, the export will fail in its entirety, and no flows will be exported. Flow limits do not apply to exports that are performed using the Workflows Export dialog.
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	2 million	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.
	Payload limit	1MB	If any single message in the flow history exceeds 1MB in size, then it will not be stored. The entry in the output field is replaced with the following message: The data returned successfully, but is too large to display. Despite the message, no error has occurred. There is no impact on the success of the flow, and the data will still be operated on as expected.
Flow Files	Attachments	10MB	The size limit on files inside flows for attachments used in action cards such as the Send Email with Attachment action card for the Gmail connector.
	Downloads and uploads	2GB	The size limit on files inside flows from download or upload action cards, such as: Upload Attachment action card for the Salesforce connector Upload File action card for the Google Drive connector Download Document in Envelope action card for the Docusign connector.
	Retention	30 days	The maximum amount of time that any file can be stored in the Workflows file system.
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	100,000	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 cell. If you update a table cell with an input that is larger than the limit, an error will be returned.
	Cell character limits	16,000	Limit on the number of characters in a table cell.
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	File payload size	100MB total, 25MB per part	For a HTTP multipart request, the maximum payload size is 100MB. For each part (file, text, password, media, and so forth), the limit is 25MB.

Latency

Workflows doesn't guarantee execution latency. In most cases, flows run very fast. However, Workflows is a multi-tenant system and does not have a latency SLA.

Flows can vary in execution time for a variety of reasons:

Complexity of the flow (including built-in waits)
Lag between increased demand for system resources and Okta adding additional capacity
Latency or rate limiting by third-party APIs

Because specific latency can't be guaranteed, Workflows shouldn't be used in any flows where execution time is critical to the scenario, such as token enrichment or customizing authorization decisions.

Hooks

There are limits on Okta events 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 password is not imported because of the read-only mode. Listeners shouldn’t delete the user password from a legacy system until they see a successful user.import.password event and not assume that the hook firing was sufficient.

Feature	Limit Type	Limit	Description
Event Hooks	Timeout	3 seconds	Okta Event 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.
	Number of daily Event Hooks	200,000	A max of 200,000 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.
	Maximum number of Event Hooks per org	10	A maximum of 10 active Event Hooks can be configured per org. Each Event Hook can be configured to deliver multiple event types.
	Maximum number of Event Hooks events per payload	100 events	A maximum of 100 events can be grouped with each Event Hook payload. Each Event Hook can be configured to deliver multiple event types.

For additional guidelines, see Event Hooks.

Automations

Okta Automations enable you to prepare and respond to situations that occur during the lifecycle of end users who are assigned to an Okta group.

Category	Title	Limit	Description
Automations	Maximum number of Automations per org	50	The maximum number of combined active and inactive Automations for your org is 50.
Maximum number of groups per Automation	10	The maximum number of groups per Automation is 10.
Maximum number of users per Automation	1 million	The maximum number of total summed users included in the group membership, that is applied to a single Automation, cannot exceed 1 million. When Automations are setup with multiple groups, the user count is incremented each time a user is added to a group. When the total number of users exceeds 1 million, the Automation doesn't run and an event is logged in the System log.

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, EU, and Asia Pacific/Japan (APJ) production and preview cells.

Okta Workflows is not covered under the Okta Business Associate Addendum (BAA), if applicable, and does not meet any Service support location requirements, data localization, nor any other HIPAA standards applicable. Okta Workflows is also not covered under Okta’s FedRAMP authorization package.