You rarely need one concurrent loop per approver. If every person must approve the same request, use Start and wait for an approval with Approve/Reject: Everyone must approve and pass the dynamic email addresses to Assigned to.
Use separate parallel branches only when the approval groups follow genuinely independent paths.
Fact-checked against current Microsoft approval documentation on 24 August 2026.
Pick the approval rule first
| Business rule | Approval design |
|---|---|
| Every assigned person must approve | Everyone must approve |
| Any one assigned person can decide | First to respond |
| Finance and Legal review independently | Parallel branches, one approval per branch |
| Approvers act in a fixed order | Sequential approval stages |
| Decision can exceed 30 days | Stored state plus separate flows |
Microsoft documents that with Everyone must approve, any rejection makes the overall approval rejected.
Build a dynamic Everyone must approve flow
1. Store approvers as people, not uncontrolled text
Use a SharePoint People column, configuration list or another governed directory-backed source. Remove blanks and duplicates before creating the approval.
Reject the request or route it for review when the approver list is empty. Do not send an approval to a guessed fallback person.
2. Build the Assigned to value
Select the email address for each approver and provide the resulting addresses to the approval action in the shape accepted by the current designer.
Inspect a test run. A SharePoint People object contains more than an email string, and passing the whole object can produce an invalid recipient.
3. Add Start and wait for an approval
Set:
- Approval type: Approve/Reject: Everyone must approve
- Title: a stable description of the request
- Assigned to: the clean dynamic approver list
- Details: the information required to decide
- Item link: the authorised source record
After the action, use its Outcome and Responses outputs. Do not infer the result from an email or from an underlying Dataverse table.
4. Record the outcome
Update the business record with:
- approval status;
- completion time;
- approval ID;
- approver responses appropriate to retain;
- next process state.
Do not write broad comments into a list that more people can read than the original approval.
When parallel branches are correct
Parallel branches are useful when different groups perform different work. For example, Finance checks cost while Security checks data handling.
Create one approval action in each branch. After the branches, combine the documented outcomes into one business decision.
This is different from putting Create an approval inside a concurrent Apply to each loop. Loop concurrency controls iteration, but it does not give you a supported cancellation or transaction model for many approval records.
Create an approval versus Start and wait
- Start and wait for an approval creates the approval and pauses the flow for the result.
- Create an approval creates the approval and lets the flow continue.
- Wait for an approval can wait for an approval created earlier.
Use Create plus Wait when you need to store the approval ID or perform other supported work between creation and waiting. Do not manipulate Microsoft-owned approval rows directly to force cancellation.
Long-running approvals
A cloud-flow run can last a maximum of 30 days, including time waiting for an approval.
Microsoft's long-running pattern stores approval state in Dataverse and uses two flows: one creates the approval, and another continues the business process when a response arrives. This is not permission to update internal approval records to simulate a cancel operation.
Reassignment, cancellation and changed approvers
Define these rules before launch:
- What happens if an approver leaves?
- Can an approval be reassigned?
- Who may cancel the business request?
- Does a changed approver list affect an approval already in progress?
- Which decision is authoritative if two runs overlap?
Use supported approval actions and business-state fields. Avoid undocumented edits to the approvals Dataverse tables.
Duplicate protection
Store an active approval ID and process version on the source record. Before creating another approval, check whether that version already has an active or completed decision.
Turn off trigger concurrency initially or use a deliberate claim step so two edits cannot create two approval requests for the same version.
Microsoft sources
- Create an approval that requires everyone to approve
- Create parallel approval workflows
- Create and test an approval workflow
- Approval action differences
- Power Automate limits
Test the business rule, not only the action
Bring the approver source, decision table and duplicate rule to the Power Automate Builders Space.