Build a Power Automate Approval Flow Without Code

A Power Automate approval flow sends a request to a named approver in Outlook or Teams, waits for their yes or no, and then runs the next step for you. You build it from a trigger, an Approvals action, and a Condition, all picked from a list rather than written. The part most first flows get wrong is what happens when nobody answers, so set a timeout and a second approver before you switch it on.

Every team has one request that moves at the speed of somebody remembering. A holiday form, a discount over ten percent, a new supplier, a purchase that needs a second pair of eyes. The work itself takes a minute. The waiting takes four days, because the request is sitting in an inbox behind ninety other emails and nobody knows whose turn it is.

An approval flow does not make the decision faster to reach. It makes the request impossible to lose, and it makes the answer permanent.

Every approval flow, whatever it approves, is the same three beats:

1. A request arrives — a form is submitted, an item is created in a SharePoint list, an email lands.
2. A named person is asked — and the flow genuinely stops here, holding its place until an answer comes back.
3. The answer drives what happens next — approved goes one way, rejected goes another, and both get written down.

The middle beat is the one that makes this different from a notification. A notification tells somebody a thing happened. An approval waits for them, and everything downstream depends on what they say.

If you already run Microsoft 365, approvals are close to a solved problem inside it. The Approvals action is first-party, so the request renders as a proper card in Outlook and in Teams with Approve and Reject buttons on it. The approver never opens Power Automate, never learns a new tool, and never needs their own automation licence. Their answer, their comment and the timestamp are all recorded against the run, which is the audit trail most approval processes are missing.

That is worth more than it sounds. Most homemade approval processes fail not because the routing is wrong but because six months later nobody can prove who said yes.

Start with where the request actually begins. The three that cover most cases:

• When an item is created (SharePoint) — the request lives in a list, which is the tidiest option because the list doubles as your record.
• When a new response is submitted (Microsoft Forms) — good when the requester should not see the list.
• When a new email arrives (Outlook) — use a shared mailbox and a subject filter, not a personal inbox.

If you are starting from a form, the SharePoint list route is worth the extra ten minutes. It gives you somewhere to write the decision back to, which the Forms-only route does not. We walk through that pairing in sending Microsoft Forms responses to a SharePoint list.

Add Start and wait for an approval. Three fields matter:

Approval type. Approve/Reject – First to respond is the right default for routine sign-off. Switch to Everyone must approve only when every named person genuinely has to see it, because each extra required approver is another place the request can stall.

Assigned to. Type the email address, or click a token from the trigger so the approver is chosen by the request itself. A token here is what turns one flow into a flow that handles every department.

Details. This is the body of the card, and it is worth more care than people give it. Put the actual decision in it: what is being asked for, how much, by whom, and a link back to the item. An approver who has to go and find the context will not answer today.

Request: [Title]
Raised by: [Created By DisplayName]
Amount: [Amount]
Open the request: [Link to item]

This is the step that separates a flow people trust from one they route around.

Set a Timeout on the Approvals action, in ISO 8601 duration format — P3D for three days. When the timeout fires, the action stops waiting and the run moves on, which means you now have somewhere to put an escalation.

Then add the escalation itself: a second Start and wait for an approval assigned to the backup, or a Teams message to the requester saying it has been chased. Either is fine. What is not fine is the default, where an unanswered request waits forever and the requester assumes it is still moving.

A flow that quietly waits forever is worse than no flow at all, because at least an email in an inbox is visible. This is the same failure shape as an automation that silently stops firing, and it is worth reading about once in general before you build several of these.

Add a Condition and compare the Approvals Outcome to Approve.

• If yes — do the thing. Update the SharePoint item's status, file the document, post to Teams, send the confirmation.
• If no — write the rejection back too, and include the approver's Comments. A rejection with no reason generates a follow-up email, which is the work you were trying to remove.

Write the outcome back to the source item in both branches. That single habit is what makes the list, rather than somebody's memory, the answer to "what happened to my request?"

Hit Test, submit a real request as yourself, and answer it from the Outlook card rather than from inside Power Automate. Then do the harder test: submit one and ignore it, and confirm the timeout fires and the escalation lands where you expected.

Most people test the happy path and ship. The happy path is not what breaks.

If your approvers are outside Microsoft 365, or the approval record needs to live in your own database, build the same shape in n8n. There is no first-party approvals card, so you assemble it: a notification node, a wait node, and a webhook URL the approver clicks to record the answer. More wiring, and in exchange you decide where the record lives and who can read it. If you have not used it before, start with the n8n basics guide.

Open Power Automate, pick the one request you chase most often, and build only the straight path: trigger, one approval, a condition, and a status written back. Skip routing, skip escalation, skip the second approver. Send yourself a test request and answer it from Outlook.

Once that single path works end to end, the timeout and the backup approver take ten more minutes, and every other approval in the business is a copy of the same four steps.

Write down the one request you chase most often, who signs it off, and what should happen on a no. Build the flow for that single path first, without routing or escalation, and send yourself a test request before anyone else sees it.