Microsoft's variable documentation, checked October 24, 2026, says Apply to each runs sequentially by default and warns that loops using variables must run sequentially when predictable variable results matter. Check the actual loop settings; do not assume concurrency was enabled.
Trace the overwrite between two actions
This original fictional flow receives two records: request R1 for address a@example.invalid and request R2 for b@example.invalid. Inside Apply to each, the design sets a shared CurrentRecipient variable and later reads it in a Compose action standing in for an outbound action.
With parallel execution enabled, this is a possible interleaving:
| Step | Iteration | Action | Shared address afterward |
|---|---|---|---|
| 1 | R1 | Set variable to a@example.invalid |
a@example.invalid |
| 2 | R2 | Set variable to b@example.invalid |
b@example.invalid |
| 3 | R1 | Compose reads CurrentRecipient | b@example.invalid |
| 4 | R2 | Compose reads CurrentRecipient | b@example.invalid |
Both reads return B's address in that schedule. Other schedules can produce different results, so a single successful run does not resolve the shared-state dependency. This trace is an authored scheduling example, not a claim that Power Automate or ChatGPT executed the flow.
Give ChatGPT the action references
Review a Power Automate cloud-flow loop without changing or running it.
Apply to each input: R1=a@example.invalid, R2=b@example.invalid.
Concurrency setting: [PASTE ACTUAL SETTING].
Actions inside loop:
1. Set flow variable CurrentRecipient to this item's email.
2. [PASTE ANY INTERVENING ACTIONS].
3. Compose the value of CurrentRecipient for this request ID.
Required result: R1 pairs with a; R2 pairs with b.
Trace an interleaving in which iteration R2 overwrites the variable
before R1 reads it. Identify every shared-variable reference.
Describe a sequential-loop repair and a direct-current-item repair.
For the second repair, explain which dynamic content or expression
must refer to the intended loop item, especially with nested loops.
Do not claim that limiting trigger concurrency fixes an inner loop.
Do not send mail, connect accounts or invent a successful flow run.
OpenAI's prompting guidance supports supplying the real dependencies. Include action names and expressions from your permitted flow definition. “Make it faster” leaves the address-to-request relationship unstated.
Choose the repair matching the dependency
If later iterations genuinely depend on previous variable values, keep the loop sequential. Inspect Apply to each settings and the actual degree of parallelism. Trigger concurrency controls separate flow runs; it is not the setting governing iterations inside this loop.
If each record can be processed independently, remove CurrentRecipient from this path and bind the consuming action directly to that iteration's email. In a nested loop, use the intended outer or inner loop reference explicitly. The repair still needs inspection of every downstream value: replacing the address while leaving a shared request ID can produce a different mismatched pair.
Test a copy using Compose outputs instead of real email or another write. Inspect both request ID and recipient for each iteration in run history. Then inspect other mutable variables before restoring the operational action.
The workflow-automation guide covers duplicate deliveries and retry identity separately. Here the failure occurs within one run: finish by showing that every iteration's composed ID and recipient remain paired under the chosen loop configuration.