Building an Approval Workflow

Analogy categoryAnalogies

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.

text

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 requester

Writing 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.