Concurrency control and pagination

What it does

Concurrency control caps how many runs of a flow, or how many iterations of an Apply to each, execute at the same time. Pagination is a per-action setting on list-style actions that tells the connector to keep fetching pages until it reaches a threshold you specify, rather than returning only the first page.

Key facts

Trigger concurrency is off by default, which means unlimited concurrent runs. Turn it on and the degree of parallelism is 1 to 100, defaulting to 25.
Turning trigger concurrency on can't be undone. Reverting means deleting the trigger and adding it back, which loses the configuration and, on some connectors, the subscription.
With trigger concurrency on, the waiting-run queue is 10 plus the degree of parallelism. Triggers arriving beyond that may be retried by the connector, and may simply not result in a run.
Apply to each runs sequentially by default. Concurrency can be set from 1 to 50.
Apply to each concurrency only applies at the top level. Nested Apply to each actions always run sequentially, whatever you set on them.
Split On debatches an array trigger payload into separate runs — up to 5,000 items on Low and 100,000 on other profiles, but only 100 items once trigger concurrency is turned on.
Pagination retrieves whole pages, so you commonly get more than your threshold. Ask for 5,000 records from a source with a 2,048 page size and you get 6,144.
Paginated items cap at 5,000 on Low and 100,000 on other profiles, and every page fetched counts as a request.

When to use / skip

Turn on Apply to each concurrency when the iterations are genuinely independent and the endpoint can take the load — bulk emails, bulk record updates, parallel approvals. Leave it off wherever iterations touch shared state, because variables are not safe under parallelism. Trigger concurrency is the riskier setting: it's the right answer when you must serialise processing of a queue, and the wrong answer almost everywhere else, because capping concurrent runs means triggers get dropped rather than queued indefinitely. Use pagination when you know the source returns more than a page and you actually need all of it; if you only need a subset, filter at source instead.

Configuration decisions

Whether ordering matters. If it does, trigger concurrency set to 1 is how you get it, and you accept the throughput cost.
The degree of parallelism on loops, balancing wall-clock time against connector throttling on the target system.
Whether pagination is enabled and what threshold, weighing completeness against request consumption and run duration.
Whether high-volume array processing should be debatched with Split On into separate runs instead of looped in one run.
Whether the work belongs in a loop at all, or in a Select and Filter array with a single bulk call.

Gotchas

Trigger concurrency is a one-way door. Someone ticks it in testing to see what it does and the flow ships with it on.
Turning trigger concurrency on silently drops the Split On limit to 100 items. Large batch payloads start losing records with nothing obvious in the run history.
Setting parallelism to 50 rarely gives 50 times the speed. Thread queuing overhead and the target endpoint's own limits dominate, and past a point you just trigger 429s.
Concurrent loops plus variables equals race conditions. Appending to an array variable inside a concurrent loop loses items non-deterministically.
Pagination is per-action and off by default. A flow that worked in test against 200 rows quietly truncates at the page boundary in production.
Not every connector action supports pagination. The setting simply isn't there, and the workaround is a Do until with skip tokens.

Consultant notes

Check trigger concurrency on every flow you inherit. It's the most common cause of "some records just don't get processed" and it never shows up as a failure.
When a client wants faster processing, look at bulk operations and Select/Filter array before you turn up parallelism. Concurrency treats the symptom.
Explain pagination in terms of the client's own data volumes. "Your SharePoint list has 12,000 items and this action returns 100" lands better than the setting name.
Concurrency, pagination and retries all multiply request consumption. If the client is anywhere near their allocation, model the numbers before switching things on.

Worth another look if the concurrency limits move, or the first time a client reports records going missing without a failed run.