An approval workflow in Power Automate routes a request to the right person, waits for a decision, and records what happened. The build is straightforward. What separates one that works from one people route around is handling the two failure cases: an approver who does not respond, and a requester who cannot see where their request is.
Why do email approvals break down?
Email approvals do not fail loudly. They fail by going quiet.
A request goes out, and then nobody can answer the only question that matters: where is it now? The requester asks the approver, the approver has forty other emails, and the trail is a thread somebody has to reconstruct. When a decision is finally made, the record of it is a message in one person's mailbox.
The cost is not the sending. It is the chasing, and the fact that nobody can audit it afterwards.
| Approval by email | Approval in Power Automate | |
|---|---|---|
| Where is the request now? | Ask the approver | Read it from the request record |
| Reminder when nobody answers | Someone remembers to chase | A branch in the flow sends it |
| Where the decision is stored | One person's mailbox | A record the whole team can query |
| Rejection | A reply that may or may not say why | A defined path with a reason and a next step |
Which approval type should you use?
The Start and wait for an approval action offers five approval types. The type decides when the flow carries on, so pick it on purpose rather than taking the default.
| Approval type | The flow continues when | Good fit |
|---|---|---|
| Approve/Reject - First to respond | Any one approver responds | A pool of equally able approvers, such as a team |
| Approve/Reject - Everyone must approve | Everyone approves, or anyone rejects | Sign-offs that are required from every party |
| Sequential approval | Each approver has responded, in order | A chain such as line manager, then finance |
| Custom Responses - Wait for one response | Any one approver picks an option | Decisions with more than yes or no, such as "Approve", "Needs changes", "Escalate" |
| Custom Responses - Wait for all responses | Every approver has picked an option | Collecting a position from several reviewers |
These are the types listed in Microsoft's approvals guide, last updated in April 2026.
How to build an approval flow
- Pick the trigger. A form submission, a new record in Dataverse or SharePoint, a file added to a library. Start from the event that already exists in the process rather than adding a new step for people to remember.
- Capture the request as a record first. Write it to Dataverse or a list before the approval starts. This is the part most people skip, and it is what makes status visible later. An approval that exists only inside a running flow is invisible.
- Add the approval action. Use Start and wait for an approval and choose the type from the table above. Put enough in the request body that the approver can decide without opening anything else.
- Branch on the outcome. Update the record, notify the requester, and carry out whatever the approval was gating. Both branches need to do something, including rejection.
- Handle the silence. Add a reminder, an escalation, or a deadline. The next section covers how.
- Make failures visible. Configure error handling so a broken run raises a flag rather than disappearing. An automation nobody trusts gets worked around.
What happens when an approver does not respond?
Nothing, unless you build something. The flow simply waits.
It does not wait forever. Microsoft's published limits say a flow run lasts at most 30 days, and that pending steps such as approvals time out after that (Power Automate limits, updated July 2026). So an ignored request sits for a month and then fails without anyone being told.
Three things fix it, and a good flow uses all of them:
- A reminder. After a day or two, nudge the approver. A parallel branch with a delay does this.
- An escalation. After a longer wait, send the request to a backup approver or the approver's manager, and tell the requester it moved.
- A deadline. Put a timeout on the approval and branch on what happens when it expires, so the requester hears "no decision in five days" instead of silence.
Agree the numbers with the people involved before you build. The thresholds are a business decision, not a technical one.
What makes an approval flow actually get used?
The requester can see status without asking. If checking on a request means messaging someone, the automation has not removed the work. It has moved it.
Approvers can decide in one place. They can respond from an Outlook email, a Teams adaptive card, or the Power Automate action center. Meet people where they already are rather than adding another site to check.
Rejections are as well handled as approvals. A rejection with no reason and no next step sends the conversation back to email, which is what you were trying to escape.
Escalation is defined up front. Decide what happens after three days before you build it, not after the first request stalls.
What should the approval record contain?
Enough that the decision can be audited later without anyone's memory:
- Who requested it, and when
- What was requested, in enough detail to judge
- Who approved or rejected it, and when
- Any comment they left
- What the system did next
If that lives in Dataverse rather than in the flow run history, it stays queryable and reportable after the run has aged out. If you are unsure where the record should live, Dataverse vs SharePoint Lists covers the decision.
Common mistakes
Automating a process nobody agreed on. If the approval path is disputed on paper, automating it makes the disagreement faster, not resolved. Settle who approves what first.
Too many approval stages. Every stage is a place a request can stall. Three sequential approvers means three chances for it to stop.
No timeout. The single most common cause of an abandoned approval process.
Rebuilding what the platform provides. The approval action handles the response UI, the notifications, and the audit record. Hand-building that with emails and a status column is more work and less reliable.
Does this need premium licensing?
Less often than people expect. The Approvals connector is a standard connector, so any license that includes Power Automate with standard connectors is enough to create approval flows. That covers Power Automate itself, Office 365, and Dynamics 365 licenses with built-in Power Automate capabilities.
Approvals are stored in Dataverse behind the scenes. In the default environment that database already exists. In another environment it is provisioned the first time an approval flow runs, and the person running that first flow needs an administrator role in the environment.
Premium licensing comes in when you add to the design: writing your own request record to Dataverse, or calling a custom connector. Settle this before building, because it changes where the record lives and that is not a decision you want to revisit mid-project.
Where to start
Take the process that generates the most chasing. Not the most complex one, and not the most important one. The one where people are spending time asking each other where something got to.
That is usually the one where automation is felt immediately, and it is the easiest place to prove the approach before extending it. If you would rather have it built than build it yourself, the Power Automate service page explains how I work.
Last updated
- Power Automate
- Approvals
- Process Automation