Build an approval flow with a reminder and a 48-hour escalation

You are building an approval that chases itself. A request comes in, the primary approver gets it, and if they have not responded in 24 hours the flow sends them one reminder. If 48 hours pass with no answer at all, the request goes to a backup approver instead of sitting in someone's inbox until the requester gives up and walks over to their desk.

To follow along you need Power Automate with a Microsoft 365 licence, a SharePoint list to raise requests from, and two people who can approve: a primary and a backup. Approvals is a standard connector, so nothing here requires a premium plan. Budget about thirty minutes. You do not need Dataverse, a custom connector, or admin rights on anything.

Why this approach, instead of sending the approval and hoping

The obvious build is one Start and wait for an approval action and nothing else. That works, and it is what most approval flows in the wild actually are. The problem is that the action has no opinion about time. Left alone it waits until the flow run itself hits Power Automate's 30-day run duration limit, which means a request can sit untouched for a month and then die quietly with nobody notified.

The fix is two mechanisms that already exist and almost nobody switches on: an action-level Timeout, and Configure run after. The Timeout puts a deadline on the wait. Configure run after gives you somewhere for the flow to go when that deadline passes, instead of failing. The reminder rides along on a parallel branch so it can run while the approval is still open.

The trade-off is honest: when the approval times out, the original task stays in the primary approver's Approvals list. Removing it needs the Dataverse Delete a row action, which is premium. So the primary can still open a request the flow has already moved on from. Step 6 handles that with a recorded outcome rather than a licence upgrade.

Step 1: Trigger the flow from the request list

Start with a SharePoint list holding the requests. Three columns carry the process: Title (what is being asked for), Status (a choice column with Pending, Approved, Rejected, Escalated), and Approver Comments (multiple lines of text).

Add the trigger When an item is created, pointed at that list. A list gives you something the reminder email can link to and something the flow can write the outcome back into. An approval with no record behind it is unauditable the moment anyone asks what happened.

Step 2: Put both approvers in variables

Add two Initialize variable actions immediately after the trigger, before anything else.

PrimaryApprover   (String)   primary.person@yourdomain.com
BackupApprover    (String)   backup.person@yourdomain.com
ApprovalDone      (Boolean)  false

PrimaryApprover and BackupApprover get referenced in three or four places each by the time this is finished. Hardcoding an address into every action means a leaver takes four edits to replace instead of one. ApprovalDone is the flag the reminder branch checks so it does not email someone who has already responded.

Step 3: Send the approval with a 48-hour deadline

Add Start and wait for an approval. Set the approval type to Approve/Reject - First to respond, the title to the list item's Title, and Assigned to to the PrimaryApprover variable.

Now the part that does the actual work. Open the action's menu (three dots), choose Settings, and set Timeout to:

PT48H

That is an ISO 8601 duration: PT for a time period, 48H for forty-eight hours. P3D is three days, PT30M is thirty minutes, P2W is two weeks. The value has to be shorter than the 30-day run duration limit, because the run dies at 30 days regardless of what you type here.

Directly after the approval action, add a Set variable that sets ApprovalDone to true. This is the signal the reminder branch is waiting on.

Step 4: Add the reminder on a parallel branch

The reminder cannot sit in the main branch. Anything placed after the approval action runs after someone has responded, which is the one moment a reminder is worthless.

Hover over the arrow between the Set variable actions in Step 2 and the approval in Step 3, and choose Add a parallel branch. On the new branch:

1. Delay - set to 24 hours.
2. Condition - ApprovalDone is equal to false.
3. On the If yes side, Send an email (V2) to PrimaryApprover.

The condition is not optional. Without it, the delay finishes and the email sends whether or not the approval was handled twenty minutes after it arrived, and the approver learns to ignore your reminders because half of them are wrong.

Put a direct link to the approver's pending approvals in the email body. Open your own Approvals page in Power Automate and copy the URL. Most people genuinely do not know where their approvals live, and a reminder that does not tell them where to go is a nag rather than a prompt.

Step 5: Catch the timeout with Configure run after

When the 48 hours pass with no response, the approval action does not sit there and it does not silently continue. It ends in a timed-out state, and by default every action after it refuses to run because they are all waiting on success.

Add a parallel branch below the approval action for the escalation path. On that branch, add a Compose action (a placeholder to hang the run-after setting on), open its menu, choose Configure run after, and tick:

has timed out

Untick is successful. This branch now runs only on the timeout, and the normal success path continues down the original branch untouched.

Step 6: Escalate to the backup and record which path won

On the escalation branch, after the Compose, add a second Start and wait for an approval assigned to BackupApprover. Give it a Timeout too, shorter than the first if the request is time-sensitive, and put the delay in the approval title so the backup knows why it landed on them:

Escalated after 48 hours: @{triggerOutputs()?['body/Title']}

Then close both paths with an Update item back into the SharePoint list. On the success path, write the primary's outcome and comments. On the escalation path, write the backup's outcome and set Status to Escalated.

That last field is what makes the premium-licence trade-off survivable. The primary approver's original task is still sitting in their queue, and if they open it late and approve, nothing downstream happens, because the flow has already moved on. The Status column is the record of which decision actually counted.

Common mistakes

Putting the reminder after the approval action.

What goes wrong: the reminder email arrives, but only after the approver has already responded. Why it happens: actions in a single branch run in sequence, and Start and wait for an approval blocks that sequence by design. How to fix it: the reminder belongs on a parallel branch that splits before the approval, so the delay is counting down while the approval is still open.

Leaving the reminder branch unguarded.

What goes wrong: someone approves within the hour and still gets chased the next day. Why it happens: the Delay action does not know or care what happened elsewhere in the flow. How to fix it: the ApprovalDone variable and the condition in Step 4. Check the flag after the delay, not before it.

Forgetting that run-after is per action, not per branch.

What goes wrong: the escalation approval runs, the backup approves, and the flow still reports as Failed. Why it happens: run-after was set on the first action of the escalation branch but not on the ones after it, so a downstream action is still waiting on a step that timed out. How to fix it: set run-after on the first action only, and let everything after it chain from that action's success. That is why Step 5 uses a Compose as the anchor.

Setting a timeout longer than the run itself.

What goes wrong: a P45D timeout that never fires. Why it happens: the flow run duration limit is 30 days, so the run is terminated before the approval action reaches its own deadline. How to fix it: keep every timeout comfortably inside 30 days. If the process genuinely needs longer, the flow has to be rebuilt to restart itself rather than wait, which is a different post.

Frequently Asked Questions

Does any of this need a premium Power Automate licence?

No. Approvals, SharePoint, Outlook, Delay and Condition are all standard connectors covered by a Microsoft 365 licence. The only premium piece is deleting the stale approval task after a timeout, which uses the Dataverse Delete a row action. Step 6 works around it with the Status column.

Do the approvers need their own Power Automate licence to respond?

No. Responding to an approval request does not require a licence of its own. The person who builds and owns the flow needs the licence; the people approving can respond from the Approvals area, Teams, or the email itself.

What happens if the backup approver ignores it too?

Whatever you tell it to. Give the second approval a Timeout as well, and add another run-after branch that emails the process owner or writes a Stalled status back to the list. Escalation chains can nest as deep as you like, as long as the total stays inside 30 days.

Can the 48 hours count business hours instead of raw hours?

Not through the Timeout setting, which is a flat duration. To skip weekends you swap the flat Delay for a Delay until action with a calculated timestamp, and calculate the deadline from the trigger's day of the week. It is more expression work, and worth it if requests routinely land on Fridays.

What if the primary approves after the escalation has already gone out?

Their response is recorded against the original approval, but nothing downstream reacts to it, because that branch of the flow ended when it timed out. The Update item in Step 6 has already written the backup's decision. This is why the Status value matters more than the approval history.

Can I send more than one reminder?

Yes. Replace the single Delay and Condition with a Do until loop that runs until ApprovalDone is true, with a Delay inside it and a count limit. Check the loop's own timeout in its settings, because it defaults to one hour, which is shorter than most approval windows and will end the loop before it has sent anything useful.

Where to go from here

The timeout and run-after settings used here are the same two mechanisms behind most reliability work in Power Automate, and they are worth understanding away from approvals specifically.

• Power Automate from Scratch, Part 1: Triggers and connectors, the mental model nobody explains covers the connector classification that decides whether a build like this one costs you anything.
• Power Automate from Scratch, Part 2: Approvals and escalation, building flows people actually respond to takes the same pattern apart at the mechanism level on the 13th, including why approvals behave differently to every other action in a flow.
• Your Power Automate flow is a single point of failure, and you've never tested what happens when it isn't there is the argument for why a backup approver is not paranoia.