Phase 5 · Power Automate · Level 2 · Practitioner
Building an approval flow
By the end, you'll be able to…
- Build a flow that pauses to ask a named person to approve or reject a request
- Branch the flow so it does one thing when approved and another when rejected
- Choose the right approval type and keep a clear record of who decided what
Why it matters
Approvals are the single most useful pattern in workplace automation, because so much real work is 'someone has to sign this off'. Power Automate has a built-in approvals feature that pauses a flow, asks a named person to decide, waits however long that takes, and then carries on based on their answer. This lesson builds a Fernway leave-request approval end to end, and shows how to branch cleanly on the outcome.
What an approval flow actually does
Most approvals at work are the same shape: someone requests something, a specific person decides yes or no, and what happens next depends on their answer. A holiday request, an expense over a threshold, a document that needs sign-off, a new supplier: all the same pattern. Power Automate turns that pattern into a built-in feature, so you don't have to invent it.
The heart of it is one action: Start and wait for an approval. When the flow reaches this step it does three things: it sends the request to the person you named, it pauses (this is the unusual part; a flow can wait hours or days without wasting anything), and when the approver responds it wakes up and hands you their outcome (Approve or Reject) plus any comment they added. The approver gets the request wherever they already work (an email in Outlook, a card in Teams, or the Approvals app), and can decide with one click. You don't have to chase anyone or build a form; the action does all of it.
Let's carry one Fernway example through: Leah, the Operations Assistant, submits a leave request, and it needs Priya, Head of Operations, to approve it before it's recorded.
Step 1: Start the flow with the request
Every approval needs a thing to approve and a way to start. A common, low-friction pattern is a Microsoft Form: Leah fills in a short leave-request form (dates, reason), and that submission is the trigger. So the flow begins with When a new response is submitted, followed by Get response details to pull the dates and reason out (the same Forms quirk from the last lesson, where the trigger alone only gives you an ID).
You could equally start an approval from an email arriving, an item added to a SharePoint list, or a button the requester presses. The starting gun doesn't matter to the approval itself; what matters is that by the end of the trigger steps you have the details the approver needs to make a decision.
Step 2: Add "Start and wait for an approval"
This is the core step. Add the Approvals action Start and wait for an approval and fill in a handful of plain fields:
- Approval type: for a simple yes/no, choose Approve/Reject: First to respond (more on the types below).
- Title: a clear one-liner the approver sees, such as "Leave request from Leah Bennett".
- Assigned to: the approver's email address; here, Priya's.
- Details: the body of the request. This is where you drop the dynamic content from the form: the dates and reason, so Priya can decide without opening anything else.
When the flow runs, Priya receives a request she can approve or reject in one click, with an optional comment. The flow simply waits until she does.
When someone submits the "Leave Request" form, get the response details, then start and wait for an approval from priya.shah@fernway.example titled "Leave request" that shows the requester's name, the dates and the reason.
Why this works: This names the trigger (a leave form submitted), the pause-and-ask step (approval to a named person) and what the approver needs to see (dates and reason). Because you know the flow uses 'Start and wait for an approval', you can check Copilot picked that action and wired the details in, rather than trusting it blind.
Step 3: Branch on the outcome
After the approval step comes a Condition, because the whole point is that yes and no lead to different places. The condition checks the approval's Outcome: if it equals Approve, do the "yes" branch; otherwise do the "no" branch.
- If approved: record the leave (add a row to a leave-tracker table or a SharePoint list), and email Leah to confirm it's booked.
- If rejected: email Leah to say it wasn't approved this time, ideally including Priya's comment so the reason travels with the answer.
That branch is what turns a notification into a real workflow. Notice both branches end by telling the requester what happened. An approval flow that decides silently is worse than no flow, because people are left guessing.
After the approval, if the outcome is approved, add the leave to the "Leave" table and email the requester to confirm the dates are booked. If it is rejected, email the requester to say it was not approved and include the approver's comment.
Why this works: This makes the two outcomes explicit (record and confirm on approve, notify with the reason on reject), which is exactly the Condition-on-Outcome structure. Spelling out both branches stops Copilot leaving the 'rejected' path empty, the most common gap in a first approval flow.
Choosing the approval type
The Start and wait for an approval action offers a few types, and picking the right one saves rework:
- Approve/Reject: First to respond is a plain yes/no; if you assign several people, the first answer decides. Right for most single-approver cases like Leah's.
- Approve/Reject: Everyone must approve means every named approver has to approve, used when a request really needs multiple sign-offs.
- Custom Responses: Wait for one / all responses lets you define your own buttons instead of Approve/Reject ("Approve", "Send back for changes", "Escalate"), for when yes/no is too blunt.
Start with First to respond; reach for the others only when the real process actually needs them. As with everything in this phase, the simplest version that matches reality is the one to build first.
When an expense is submitted, if the amount is £500 or more, start and wait for an approval from dan.okafor@fernway.example before recording it; if it is under £500, record it straight away without approval.
Why this works: This shows approvals combined with a condition on the amount, so only larger expenses need sign-off, a very common real pattern. It names the approver and the threshold, giving Copilot a buildable spec you can then verify step by step.
Try it now
Common mistakes
- Leaving the rejected branch empty. If only the "approved" path does anything, a rejected request vanishes and the requester never hears back. Always handle both outcomes, even if "no" just means an email.
- Assigning the approval to the wrong person, or to no one reachable. The flow waits forever for someone who never sees it. Double-check the approver's address, and consider who covers approvals when they're on leave.
- Choosing "Everyone must approve" when you meant "first to respond". These behave very differently; the wrong choice either stalls waiting for people who needn't decide, or approves on a single answer when you wanted consensus.
- Trusting the record without reading the decision. The flow faithfully carries out whichever branch the outcome triggers, but if you assigned the wrong approver, or the details were incomplete, it will record an approval that shouldn't have been given, at full speed and with total confidence. The approval feature routes the decision; the judgement about who decides and what they saw is still yours to get right.
Keeping current
The approvals feature is well established, but Microsoft evolves the action names and the Approvals app over time. Microsoft's Get started with Power Automate approvals and Create and test an approval workflow on Microsoft Learn track the current screens. Accurate as of 13 July 2026.