An Apply to each loop in a cloud flow processes 500 Dataverse rows one at a time and takes too long. Each iteration calls an API and also increments a shared counter variable that is used after the loop. The developer wants iterations to run in parallel without producing wrong results. What should the developer do?

Apply to each runs sequentially by default. Its concurrency control setting allows several iterations to run at the same time up to a configured degree of parallelism, which shortens total duration when each iteration waits on an external call. The cost is that iterations no longer run in a predictable order, and variables are shared across all iterations of the run. Updating a shared variable from parallel iterations can produce unpredictable results, so the safe pattern is to have each iteration produce its own output, such as a Compose action or a returned value, and then compute totals after the loop with expressions over the collected outputs, or with a Filter array or Select action over the source data. Assuming increments are atomic in parallel loops is the trap; Microsoft cautions that variable values are unreliable when iterations run concurrently. Adding a Delay inside a sequential loop only lengthens the run and does nothing to speed up Dataverse. Trigger concurrency controls how many separate runs of the flow execute at once; it does not split the rows of one run's loop across runs, so the loop inside each run is unchanged. Exam caveat: parallel iterations increase the request rate against Dataverse and other APIs, so service protection limits and connector throttling still apply. Operational check: compare total duration and the final count in a test run with concurrency on against a sequential baseline.