Concurrency SLA

Paragon’s concurrency SLA is the number of workflow step executions that can run at the same time across all of your Connected Users. This is a shared pool of execution capacity for Workflows for your subscription. For example, if you have a concurrency SLA of 20, Paragon can run up to 20 workflow steps in the background at the same time. Those 20 step executions could come from 20 different workflows, several Connected Users triggering the same workflow, or a single workflow that fans out into many steps.

​

Concurrency Levels

Our Concurrency SLA for our standard plans is as follows: Enterprise customers may contact their Customer Success Manager to configure their Concurrency SLA.

​

How concurrency works

When a workflow is triggered, Paragon queues the work to begin the execution and queues each step following until the Workflow is completed. If concurrency capacity is available, the step begins running. If all concurrency slots are already in use, the step remains queued until another step finishes and a slot becomes available. Concurrency is shared across your workflows and Connected Users. For example, with a concurrency SLA of 20:

• If 12 step executions are running for User A and 8 are running for User B, your subscription is using all 20 slots.
• If another workflow is triggered while those 20 slots are in use, Paragon accepts the new execution but waits to run its next step.
• When one of the running steps finishes, queued work can begin using the freed slot.

​

How queued work is prioritized

When a workflow execution is submitted, Paragon assigns it a queue priority. Most workflows are prioritized in the order they arrive, and queued steps later in the same workflow keep that original priority. This means standard workflow executions generally continue moving from start to finish in arrival order as concurrency slots become available. Request-triggered workflows that include a Response step are treated differently: because the original HTTP request is waiting for Paragon to reach the Response step, these workflows receive a higher priority than standard asynchronous workflows. This helps Paragon return the synchronous response before the request timeout. Request-triggered workflows without a Response step do not use this higher-priority path; they return 202 Accepted immediately and continue as standard asynchronous workflow executions.

​

High-volume workflow handling

Fan Out steps can create many step executions at once because each item in the array runs the steps inside the Fan Out branch. A large Fan Out occurs when the array passed into the Fan Out resolves to 50 or more items. For example, a workflow that queries 75 new records and then fans out over those records is treated as a large Fan Out. Paragon treats these Fan Outs differently because one workflow can suddenly create thousands of branch executions. To keep that high-volume work from crowding the standard workflow execution queue, Paragon routes large Fan Out work into a dedicated queue. Dedicated Fan Out queues help isolate high-volume Fan Out work from other workflow execution queues, but they do not bypass your concurrency SLA. They are still part of the same shared concurrency pool for your subscription. Dedicated queues receive a concurrency assignment based on the current queue backpressure (in pending/waiting step executions). The Workflow Engine automatically balances available concurrency slots between your project’s queues based on backpressure. For example, if a workflow fans out over 1,000 records and the first step inside the Fan Out is an integration action:

• Paragon will detect a large Fan Out, so the workflow will not run 1,000 integration actions simultaneously.
• Fan Out branch executions will wait in the dedicated Fan Out queue and run as concurrency slots and workers are available.
• Multiple concurrency units may be used if multiple branch executions are running at the same time, capped by your subscription’s shared concurrency SLA (shared with work occuring in other workflows).

​

What happens if I reach my Concurrency SLA?

When you reach this SLA, Paragon does not reject new workflow executions because of concurrency. New step executions are queued and show as Not Started on the Monitoring page, under the Workflows tab. In filters and API responses, this queued state may also appear as QUEUED or NOT_STARTED. Paragon accepts and stores all queued executions. They begin running once the number of active step executions drops below your concurrency SLA.