11.3 Managing Approvals with Cloud Flows

Power Automate's Approvals connector turns human sign-off into a first-class flow step. Approval requests, responses, and history are stored in Microsoft Dataverse, which is why the same request surfaces everywhere: the Approvals app in Microsoft Teams, the approval center in the Power Automate portal, and Outlook actionable messages that let the approver click Approve or Reject with comments without leaving the inbox.

Start and Wait vs Create + Wait

There are two structural patterns, and the exam tests the difference directly:

• Start and wait for an approval — one action that creates the approval, sends the notifications, and pauses the flow run until the approval completes. Outputs (Outcome, Responses, comments) are available on the very next step. Use it for the common case: nothing else should happen until someone decides.
• Create an approval + Wait for an approval — the Create action starts the approval and its notifications but returns immediately, handing back an approval ID. The flow keeps running — provisioning accounts, generating documents, updating rows — and only when it needs the verdict does Wait for an approval (fed the approval ID) pause until completion. Choose this pattern when work must proceed in parallel with the decision, or when you need custom timeout handling.

Exam trap: 'Create an approval' by itself does not wait — a condition placed immediately after it reads empty outputs. And because approvals live inside cloud flows, the 30-day maximum flow run duration applies; an approval that sits unanswered for 30 days kills its run.

The Four Approval Types

Sequential approvals are not a fifth type — they are a pattern: place a second Start and wait for an approval after the first, so the pre-approver (for example, the direct manager) must sign off before the final approver (Finance) ever sees the request. Microsoft's own vacation-request walkthrough uses exactly this chaining.

Key Fields and Outputs

The required fields are Title and Assigned to (semicolon-separated email addresses or UPNs; several people listed share one approval governed by the type's completion rule). Details accepts Markdown formatting, and Item link plus Item link description render a 'go to the record' button in Teams and Outlook — point it at the SharePoint item or model-driven app record under review.

Outputs you will route into later steps: Outcome, the Responses array (responder name, responder email, response, comments, response date), completion date, and response summary. Comparisons against response text are case-sensitive: Approve does not equal approve. That case-sensitivity is a documented gotcha and a classic exam distractor.

Where Approvers Act, and Reassignment

Approvers can respond from Outlook (the actionable message with Approve/Reject buttons and a comment box), Teams (the Approvals app, plus adaptive cards delivered in the activity feed), or the Power Automate portal approval center. All three surfaces act on the same Dataverse-backed request, so a decision made anywhere is reflected everywhere. An approver who is the wrong person — or is about to go on leave — can reassign the request to someone else, optionally with a comment; reassignment is recorded in the approval history. Requesters and administrators can monitor everything from the Approvals app or, at platform depth, directly against the approvals tables in Dataverse.

Capturing Results into Dataverse

Approval history exists in Dataverse automatically, but the business record needs its own audit trail. After the wait step, update the originating row: set a Status choice to the Outcome, stamp the responder name and response date, and store Responses comments in a multiline column — the same write-back Microsoft's vacation-request tutorial performs against SharePoint with an Update item action. For approval-heavy solutions, many teams also Add a row to a custom Approval Log table per response, so multi-stage chains stay queryable from model-driven apps.

Escalation: The Parallel-Branch Pattern (Awareness)

Approvals have no built-in 'escalate after N days' switch, so makers build one. The standard pattern:

1. Use Create an approval (not Start and wait).
2. Add a parallel branch next to the Wait action containing a Delay — say 2 days.
3. In the delay branch, check a status flag; if the approval is still pending, send a reminder (Teams message or email), route a new approval to the manager's manager, or reassign the request.
4. After the Wait completes, set a flag (for example isComplete = true) so the delay branch's condition exits quietly instead of firing a spurious reminder.

Know this at awareness level: recognize the pattern in a diagram and understand why Create + Wait is required to make it possible — a single Start-and-wait action blocks the run, leaving no room for a parallel reminder branch.

Walkthrough: PTO Approval End to End

An employee adds a row to a SharePoint Vacation Requests list. The flow:

1. Trigger: SharePoint When an item is created (Site Address + List Name).
2. Office 365 Users – Get manager (V2) on Created By Email to resolve the approver.
3. Start and wait for an approval — type Approve/Reject – First to respond, Assigned to = manager and the HR backup (either one can decide), Title containing the employee name and dates, Details in Markdown, Item link pointing at the list item.
4. Condition: Outcome is equal to Approve — exact case.
   • If yes: SharePoint Update item (Approved = Yes, Manager comments = Responses comments) → Send an email (V2) to Created By Email: 'Your vacation request has been approved by [Responses Approver name]'.
   • If no: Update item with the rejection and comments → Send an email (V2) stating the reason.

Add the escalation variant by switching to Create + Wait with a 2-day delay branch that pings the manager in Teams. That single flow exercises nearly every approval concept AB-410 measures: trigger choice, approver resolution, completion rules, case-sensitive outcome handling, write-back, and notifications.