Flow Level Concurrency

Limiting concurrent runs for a process flow

Introduction

Every company profile has a concurrent process flows allowance - the maximum number of process flows that can run at the same time across your whole account. This allowance is determined by your Patchworks subscription and is shared by all of your process flows.

By default, there's no cap on how much of that allowance a single process flow can use. If several run jobs for the same flow are waiting in your queue, they're picked and run in parallel whenever slots are available.

The maximum concurrent runs setting lets you set a lower limit for an individual process flow, within your account allowance. Once the number of running instances of that flow reaches the limit, any further run jobs wait in your queue until one finishes.

This setting is optional. Process flows with no maximum concurrent runs value behave as they always have - they can use as much of your concurrent process flows allowance as the queue gives them.

When to use this setting

Scenario	Without a limit	With a limit
Scheduled flows and backlogs. A flow runs on a schedule (e.g. every 10 minutes) and normally completes well within that interval.	If a backlog builds up in your queue, new scheduled run jobs keep being added. When the backlog clears, several instances of the same flow can start at the same time.	Set maximum concurrent runs to 1 so runs of this flow are always processed one at a time, in the order they were queued.
Parent/child fan-out. A parent flow uses the run process flow shape to start a child flow for each record - for example, one per order.	Hundreds or thousands of child run jobs can be queued at once, and as many as your account allowance permits will run in parallel - often causing rate-limiting or throttling errors in downstream systems.	Set maximum concurrent runs on the child flow to control how many instances run at once - for example, 5.
Flows that shouldn't overlap. A flow depends on the previous run having finished - for example, it works with a shared file, a cache, or data written by the previous run.	Overlapping runs can process the same records twice or interfere with each other.	Set maximum concurrent runs to 1.

How it works

When a run job for a process flow is due to be picked from your queue, Patchworks checks how many instances of that flow are currently running:

• If the number is below the flow's maximum concurrent runs limit, the run job is picked and started as normal.

• If the number is at the limit, the run job stays in your queue. It's picked as soon as one of the running instances completes, subject to the usual queue order and priority.

Points to note:

• This is a per-flow limit within your account allowance. A process flow can never run more instances than your concurrent process flows allowance permits, whatever value is entered here.

• Run jobs held by this limit are waiting in your queue, not running - so they don't use a concurrent process flows slot, and other flows aren't blocked while they wait.

• Held run jobs still count towards your scheduled process flows allowance. If a flow is triggered much more often than it can complete, its queued run jobs will keep building up - in this case, consider lengthening the schedule interval, or remove queued runs for the flow from the queue tab.

• Held run jobs may wait in your queue for longer than usual. If the flow uses relative dates, check the use queued time option in process flow settings to make sure the right base time is used.

Setting a maximum concurrent runs limit

1

Access process flow settings

Open the required process flow and click the settings (cog) icon in the canvas actions bar.

2

Expand advanced settings

Click advanced settings to expand this section.

3

Enter a limit

In the maximum concurrent runs field, enter the maximum number of instances of this flow that can run at the same time - for example:

The value must be a whole number of 1 or more. To remove an existing limit, clear the field.

4

Save your changes

Click the save button.

Changing the limit doesn't affect instances that are already running. The new value is applied the next time a run job for this flow is picked from your queue.

Maximum concurrent runs vs connection pools

If you've previously used connection pools to protect a downstream system from too many simultaneous requests, it's worth understanding how the two options differ:

	Maximum concurrent runs	Connection pools
What is limited	The number of instances of one process flow that can run at the same time	The number of simultaneous requests made to a connector instance, across every flow that uses it
Where the wait happens	In your queue, before the run starts	Inside a running flow, at the connector step
Uses a concurrent process flows slot while waiting?	No	Yes - the flow is already running, so it holds a slot until a pool slot is released
Best for	Stopping the same flow stacking up in parallel - scheduled backlogs and parent/child fan-out	Enforcing a system's concurrency limit across several different flows that share a connector instance

The two can be used together: set maximum concurrent runs to keep the number of running instances of a flow sensible, and use a connection pool to enforce the exact concurrency limit of the target system.

Related information

• Process flow settings

• Working with your run queue

• Run process flow shape

• Connection pools

• Subscription tier limits