Okta Workflows doesn’t guarantee execution latency. Usually flows run very fast. However, Workflows is a multi-tenant system and doesn’t have a latency SLA.
Flows execution times depend on:
- Complexity of the flow (including built-in waits)
- Lag between increased demand for system resources and Okta adding extra capacity
- Latency or rate limiting by third-party APIs
Because specific latency can’t be guaranteed, up until now, Workflows shouldn’t be used in any flows where execution time is critical to the scenario, such as token enrichment or customizing authorization decisions. As an example, Okta inline hooks have a completion timeout of three seconds with a single retry, so it was ill advised to implement the service endpoint with Okta Workflows, as there was no guarantee that a response would be returned in under 3 seconds.
The addition of Low Latency Flows has now opened up a whole new set of use cases that can be satisfied with Okta Workflows.
Supported Use Cases
With the Low-latency feature, the following use cases are now supported:
| Condition | Example use case |
|---|---|
| Flow begins with the API Endpoint card | Inline hooks |
| Flow starts with any of the Okta connector event cards | First-party event hooks |
| Flow starts with a webhook from a third party through a connector card | Third-party webhooks |
| Flow uses a Delegated Flow event card | Delegated flows |
Execution Queues
It’s all to do with execution queues.
Every workflow requires a certain duration to complete. The total time required is composed of two factors: the time spent waiting for the flow to execute and the actual execution time. The image below depicts the flow execution before the release of Low Latency flows:
From the above diagram, flows that would be eligible for low-latency mode are being held up by large or throttled flows. These low-latency flows must wait until these longer-duration flows have completed.
The Low-latency feature ensures consistent execution times for your flows by running flows that meet a specific set of criteria separately from those that don’t. Okta routes low-latency flows to an optimized processing queue with minimal wait times and increased resource availability. These flows execute at a higher velocity compared to flows that run in standard mode or flows that get throttled.
After the release of the Low-latency feature, the flow execution queues would look like the following:
Okta moves all the low-latency eligible flows into their own queue, removing them from the constraint of being behind large or throttled flows in the standard queue. The low latency flows execute at a higher and more consistent velocity, improving your business processes.
Low Latency Qualification
So how do flows qualify for the Low latency Queue?
There are technical requirements that your flow must meet to run in low-latency mode. If your flow violates any of the following constraints, Okta removes it from the low-latency mode and returns it to the standard mode for execution.
| Constraint | Description |
|---|---|
| Excess resource usage | Flow exceeds the resource constraint limits for execution. |
| Rate limits | Flow uses a third-party connector and receives an HTTP 429 Too Many Requests error or any other rate limit error. |
| Explicit pauses | Flow explicitly pauses the execution using one of the Wait For, Wait Until or Pause cards. |
| Timeouts | Flow doesn’t finish within the default timeout period for an HTTP connection (60 seconds). |
| Streaming actions | Flow uses connector cards with data streaming. These cards are designed to process large datasets and rarely finish within the timeout limit. |
| Using asynchronous features | Flow is marked to run in the background without blocking another flow. For example, the Call Flow Async card.For function cards that call a helper flow synchronously, the helper flow starts in low-latency mode but is subject to the same constraints as the parent flow.If the parent calls a helper flow asynchronously, the parent flow can continue in low-latency mode. However, the helper flow isn’t eligible for low-latency mode and executes in standard mode. |
| HTTP Close card | Flow uses the HTTP Close card to manually close a connection.The HTTP Close card is eligible for low-latency mode. However, using it causes the remainder of the flow to be ineligible for low latency mode, because it implies that the rest of the flow executes asynchronously. |
Basic Test
This is a very basic test and it does not represent actual execution times. The way I ran my test was to call the same helper flow in both a synchronous and asynchronous manner. Because the flow begins with the API Endpoint card, it qualifies for the Low Latency Queue and so does the helper flow when called synchronously. But when the same helper flow is called asynchronously, it is not eligible for low-latency mode and executes in standard mode.
After executing the parent flow a number of times, let’s look at the flow history of the helper flow. The helper flow was executed twice for each invocation of the parent flow, once in synchronous mode and once in asynchronous mode. From the flow history we can see which flow ran in the Low Latency Queue and which flow ran in the Standard Queue.
See this page for additional information on Low Latency Flows: Criteria for low-latency flows | Okta
3 thoughts on “Low Latency Flows”