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:

  • Large scale (50K records at a time) inbound events and writes to third party systems (such as provisioning or messaging)
  • Large scale (100K) table operations (such as write or read)
  • Moderate scale (10K) user import with Inline Hooks and simple transformations
  • Moderate reads (2K or more) from Okta

Workflows is well-suited for such operations.

These use cases require monitoring, attention to architecture, and awareness of system limits:

  • Large scale (10K or more records at a time) reads from spreadsheet apps or comma-delimited files
  • Moderate scale (10K) user import with Inline Hooks (Import Inline Hook or Registration Inline Hook with multiple external calls
  • Large data processing (more than 100MB) within a single Flow.
  • Large scale custom integrations via an HTTP request card

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:

  • Full user data imports, directory synchronization, or large scale reads.
  • Flows with real-time requirements (sub-second completion)
  • Flows for on-premises scenarios
  • Synchronous Flows outside of the Import or Registration Inline Hooks

 

Workflows platform limits

Category Title Limit Description
Flows

 

 Number of active Flows per Org 100

Only 100 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.

Number of flows in an exported folder

400

There's no maximum number of Flows that can be in a folder. However, to successfully export a folder, the number of Flows should be kept below this limit.
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.

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.

Note

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

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.

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 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.

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.

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.

Maximum number of Inline Hooks per org

50

The maximum number of Inline Hooks that can be configured per org is 50, which is a combined total for any combination of Inline Hook types.

For additional guidelines, see Event Hooks and Inline 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

1M

The maximum number of total summed users included in the group membership, that is applied to a single Automation, cannot exceed 1M.

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 1M, the Automation doesn't run and an event is logged in the System log.

For additional guidelines, see Automations.

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.