Concurrency Control in Power Automate: Preventing Duplicate Runs

If your scheduled Power Automate flow processes records from a shared data source, concurrent runs can cause duplicate processing, data corruption, or throttling. Here is how to control it.

The Default Behavior

By default, trigger-based flows run with concurrency control off — the platform fires every triggered run as it arrives, in parallel, with no upper bound on overlap. When you turn concurrency control on, the default Degree of Parallelism is 20, configurable from 1 up to 50. For scheduled flows, if a previous run hasn't finished when the next schedule triggers, both run simultaneously.

This is fine for stateless notifications. It is a problem for anything that reads, transforms, and writes data.

Setting Concurrency Control

On Triggers

1. Click the trigger action (e.g., Recurrence or When an item is created)
2. Go to Settings
3. Toggle Concurrency Control to On
4. Set Degree of Parallelism to 1

With parallelism set to 1, only one instance of the flow runs at a time. Additional triggers queue up and execute sequentially.

On Apply to Each Loops

The same setting exists on Apply to each actions:

1. Click Settings on the Apply to each
2. Toggle Concurrency Control to On
3. Set the degree of parallelism (1 for sequential, higher for parallel)

Setting this to 1 processes items one at a time — slower but safe when order matters or when you are hitting API rate limits.

When to Use Each Setting

Scenario	Trigger Concurrency	Loop Concurrency
Batch processing records	1	1-5
Sending notifications	Default (off / unbounded) or DoP 20	10-20
Updating a shared counter	1	1
Independent API calls	Default	20-50

The Queue Behavior

When concurrency is set to 1 and multiple triggers fire, the extra runs enter a queue. Important details:

• The waiting-runs limit is configurable via the trigger's settings — the range Microsoft documents is roughly 10 plus the Degree of Parallelism, up to 100. The default is on the small end of that range, so don't assume you have headroom for thousands of waiting runs
• Runs that overflow the queue can still be retried by the calling connector (the platform won't drop them silently — but the retry semantics depend on the connector)
• You can monitor queued runs in the flow's run history

Combining with Duplicate Detection

Even with concurrency control, design your flows defensively:

• Idempotent operations: make sure running the same action twice produces the same result
• Status fields: mark records as "processing" before starting, "completed" when done
• Timestamp checks: skip records that were already processed within a time window

Key Takeaway

Set trigger concurrency to 1 for any flow that modifies shared data. The performance trade-off is almost always worth the data integrity guarantee. Parallel execution is an optimization — reach for it only when you have confirmed your logic is safe to run concurrently.