Control concurrency in Apply to each to avoid throttling

Did you know that Apply to each runs one item at a time by default? That’s why a flow that processes 200 SharePoint items can take 10+ minutes when it could take 30 seconds. The fix is hidden behind a single setting — but you have to use it carefully.

The setting

Open any Apply to each action → ⋮ menu → Settings → Concurrency Control → On. You’ll see a slider from 1 to 50. That number is the degree of parallelism: how many iterations run at the same time.

Flip it from off to 20 and a long-running batch flow can finish in a fraction of the time.

Why “max it out” is the wrong instinct

More parallelism is not always better. Two things break when you push the slider too high:

1. API throttling. Every connector has limits — SharePoint, Dataverse, SQL, Graph, custom APIs. Run 50 calls per second and you’ll start seeing 429 (Too Many Requests) errors and random failures that look like bugs but are throttling.
2. Backend pressure. Even when the connector accepts the calls, the backend system might not. A SQL Server with 4 cores doesn’t enjoy 50 concurrent UPDATEs landing at once.

Variables and concurrency don’t mix

This is the bug everyone hits exactly once. Inside an Apply to each running in parallel, two iterations can:

• Read the same variable at the same time.
• Both compute a new value.
• Write back, overwriting each other.

Result: counters that skip values, totals that drift, lists that lose entries. The fix is to avoid Set variable and Append to variable inside concurrent loops. Use Compose actions to capture per-iteration values, then aggregate after the loop with union(), xpath(), or a Filter array.

A practical recipe

1. Start with concurrency = 2 to confirm logic works correctly in parallel.
2. Bump to 5, then 10, watching run history for throttling errors.
3. If you hit 429s, back off and add Delay actions or use a Do until with retry logic.
4. Settle on the highest stable value — most real workloads land between 5 and 20.
5. Replace any variable operations inside the loop with Compose + post-loop aggregation.

When not to use concurrency

• Order matters (the loop builds something step by step, like a paged API).
• Side effects must be sequential (sending notifications in chronological order).
• The downstream system has a single-writer constraint (file appends, sequential approvals).

Why this matters

Concurrency is the single biggest “free” speedup you can give a Power Automate flow. Done right, you go from 10-minute runs to 30 seconds without changing your business logic. Done wrong, you turn a working flow into an intermittent mystery. Pick a number, watch the runs, and adjust — that’s the whole job.