Anatomy of an Approval Flow
A standard approval workflow begins with a trigger such as 'When an item is created' on a SharePoint list or 'For a selected item' for manual submission, then calls the 'Start and wait for an approval' action from the Approvals connector, specifying the approval type (single approver, everyone must approve, or first to respond), the approver's email, and a title and details string pulled from the triggering item's dynamic content. The action pauses the flow and creates a task both in the Power Automate mobile/web Approvals center and, if configured, a Teams adaptive card, until the approver responds or the flow's timeout is reached.
Cricket analogy: A DRS review pauses live play entirely until the third umpire renders a decision, the same way 'Start and wait for an approval' halts the flow's execution until the approver responds.
Handling Multi-Stage and Conditional Approvals
For a multi-stage approval — say, a manager approval followed by a finance approval only if the request exceeds a dollar threshold — chain a second 'Start and wait for an approval' action inside a Condition branch that checks the outcome of the first, using outputs('Start_and_wait_for_an_approval')?['body/outcome'] to branch on Approve versus Reject, and reference the manager's email dynamically via the Office 365 'Get manager (V2)' action rather than hardcoding it, so the flow adapts automatically as reporting lines change. When more than one approver must weigh in in parallel rather than in sequence, use the 'Everyone must approve' approval type on a single action instead of chaining separate approval actions, since chaining would force approvers to respond sequentially rather than concurrently.
Cricket analogy: A bowling change goes through the captain first and only escalates to the coach's input if the situation is critical, a sequential escalation mirroring a manager-then-finance approval chain gated by a condition.
Trigger: When an item is created (SharePoint - Expense Requests)
-> Get manager (V2) [User (UPN): triggerOutputs()?['body/Author/Email']]
-> Start and wait for an approval
Approval type: Approve/Reject - First to respond
Title: Expense approval for @{triggerBody()?['Title']}
Assigned to: outputs('Get_manager_(V2)')?['body/mail']
-> Condition: outputs('Start_and_wait_for_an_approval')?['body/outcome'] is equal to Approve
If yes AND triggerBody()?['Amount'] > 1000:
-> Start and wait for an approval (Finance team)
If yes AND amount <= 1000:
-> Update item: Status = Approved
If no:
-> Update item: Status = Rejected
-> Send an email notification to requesterWriting Back the Outcome and Notifying the Requester
After the approval outcome branches, always write the final status back to the source item — an 'Update item' action on the SharePoint list setting a Status column to Approved or Rejected — so the record of truth lives in the business system, not only in the flow's run history, which most requesters will never think to check. Pair that update with a 'Send an email (V2)' or 'Post adaptive card and wait for a response' notification back to the original requester that includes the approver's comments field from the approval response, since silently updating a status column without notifying the requester leaves them polling the list manually to find out what happened.
Cricket analogy: The official scorecard, not a fan's memory of the game, is the permanent record of a match's result, mirroring how the SharePoint Status column — not the flow's run history — is the durable record of an approval's outcome.
If the flow's trigger is 'When an item is created' but the flow also updates that same item's Status column, make sure the update does not use a trigger condition or filter that causes the flow to re-trigger itself — updating an item that was just created does not re-fire a 'created' trigger, but a poorly scoped 'When an item is created or modified' trigger on the same list can cause an infinite loop if it isn't excluded from firing on its own status update.
Testing and Handling Approval Timeouts
Every 'Start and wait for an approval' action has a configurable timeout (default 30 days) after which the flow proceeds automatically with an outcome that must be handled explicitly — typically by escalating to a backup approver or auto-rejecting with a note that the request expired — rather than leaving the Condition branch to fail silently on an unexpected outcome value. Test the flow using the Power Automate mobile app's Approvals tab to actually approve or reject as a real approver would, not just by inspecting the flow's test run history, since the mobile and Teams adaptive card experiences sometimes surface fields differently than the designer's simulated test run.
Cricket analogy: A rain-affected match has a defined reserve-day cutoff after which the result is decided by a fallback method like the Duckworth-Lewis calculation rather than staying undecided indefinitely, mirroring an approval's timeout forcing a fallback outcome.
Use 'Post adaptive card and wait for a response' instead of 'Start and wait for an approval' when you need a richer response than Approve/Reject — for example, capturing a free-text comment, a dropdown selection, or multiple fields from the approver in a single interactive Teams card.
- 'Start and wait for an approval' pauses flow execution until the assigned approver responds or the configured timeout is reached.
- Use 'Everyone must approve' for true parallel approval, not chained sequential approval actions.
- Branch on outputs('...')?['body/outcome'] to route Approve versus Reject logic, adding threshold-based Conditions for multi-stage escalation.
- Reference approvers dynamically (e.g. Get manager V2) rather than hardcoding email addresses.
- Always write the final outcome back to the source list item so it isn't only visible in flow run history.
- Notify the requester with the approver's comments, not just a silent status change.
- Explicitly handle the approval's timeout outcome rather than assuming Approve/Reject are the only possible results.
- Test using the real mobile/Teams Approvals experience, not only the designer's simulated test run.
Practice what you learned
1. Which action pauses a Power Automate flow until a human approver responds?
2. How should a flow handle a case where two approvers must both sign off in parallel?
3. Why is it important to update the source SharePoint item's Status column after an approval decision?
4. What is the default timeout for a 'Start and wait for an approval' action if not otherwise configured?
5. When would you use 'Post adaptive card and wait for a response' instead of 'Start and wait for an approval'?
Was this page helpful?
You May Also Like
Power Automate Best Practices
Field-tested guidelines for building Power Automate flows that stay maintainable, resilient to failure, and easy to govern once they hit production.
Power Automate Quick Reference
A condensed reference of core Power Automate concepts, expressions, and connector actions for quick lookup while building flows.
Power Automate Interview Questions
Commonly asked Power Automate interview questions covering trigger types, error handling, licensing, and real-world troubleshooting scenarios, with model answers.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics