How to Build a Power Automate Approval Workflow That Your Team Will Actually Use

Every organization has approval processes. Purchase requests need a manager's sign-off. Expense reports need finance review. Leave applications need team lead confirmation. Document drafts need stakeholder approval before distribution. These processes exist everywhere. And in most organizations, they run through email.

Someone submits a request. Emails are sent. Forwarded. Replied to with questions. Forwarded again. The approver is traveling and doesn't see the email for three days. The requester sends a "gentle follow-up." Another two days pass. Eventually, the approval happens, but it took a week for something that should take hours. Nobody knows the status of any pending request without asking a person. There's no audit trail. There's no escalation path. And there's certainly no dashboard showing how many approvals are bottlenecked at any given moment.

Power Automate solves this completely. But not if the workflow is built poorly. A bad approval flow is worse than no approval flow because it creates a false sense of automation while still requiring manual intervention at every step. This guide walks you through how to build approval workflows that actually work in production, with the design patterns, escalation logic, and error handling that separate a demo from a system your team relies on daily.

The real problem with most approval workflows is not technical

The most common reason approval workflows fail isn't a configuration error or a missing connector. It's that the workflow was built to replicate an existing broken process instead of redesigning it. If your current email-based approval takes five steps and involves three people, the instinct is to build a Power Automate flow with five steps and three people. But the question nobody asks is: do all five steps add value? Do all three approvers need to be involved? Is the process itself the problem?

Before building anything in Power Automate, map the current approval process on paper. Every step. Every decision point. Every handoff. Every wait. Then ask: which steps exist because of a genuine business requirement, and which steps exist because "that's how we've always done it"? In my experience, 30 to 40% of steps in most approval processes are pure overhead that can be eliminated before any automation begins.

Before you build anything, get these three things right

First, define the data source. Every approval workflow needs a place where requests live. In the Microsoft 365 ecosystem, that's typically a SharePoint list or a Dataverse table. The list captures all the information the approver needs to make a decision: who's requesting, what they're requesting, the amount or impact, supporting documents, and the current status. Design this list before building the flow. The quality of the list design directly determines the quality of the workflow.

Second, define the approval rules. Who approves what? Is it always the same person? Does it depend on the amount (under $5,000 goes to the manager, over $5,000 goes to the director)? Does it depend on the department? Is it sequential (manager first, then finance) or parallel (manager and finance at the same time)? Write these rules down before opening Power Automate. Ambiguous rules create ambiguous flows.

Third, define what happens after approval and after rejection. Approval is not the end of the process. What happens next? Does the requester get notified? Does the status update in the list? Does a downstream process trigger (like generating a purchase order or updating a budget tracker)? And if the request is rejected: does the requester get feedback on why? Can they revise and resubmit? Or is the request closed permanently? These decisions shape the entire flow architecture.

The four types of approval workflows and when to use each

Sequential approval routes the request through approvers one at a time, in order. Approver A reviews first. If approved, it moves to Approver B. If Approver B approves, it moves to Approver C. This is the right pattern when each approver's decision depends on the previous approver's judgment. Common examples: purchase requests escalating from manager to director to VP based on threshold amounts.

Parallel approval sends the request to multiple approvers simultaneously. All approvers review at the same time. The request proceeds only when all have responded (or when the first response is received, depending on configuration). This is the right pattern when multiple departments need to sign off independently. Common examples: a new vendor registration that needs approval from both Procurement and Legal.

First-to-respond approval sends the request to multiple approvers, and the first person to respond decides the outcome. This is useful when you have a group of interchangeable approvers and speed matters more than who specifically approves it. Common example: a content review where any member of the editorial team can approve.

Conditional approval routes the request to different approvers based on the data in the request itself. If the amount is under $5,000, it goes to the department manager. If it's between $5,000 and $25,000, it goes to the director. If it's over $25,000, it goes to the VP. This is the most common pattern in enterprise environments and requires condition logic in the flow.

Anatomy of a well-built approval flow

Every production-quality approval workflow, regardless of type, should include these components. Missing any one of them is the difference between a demo that impresses and a system that lasts.

A trigger that starts the flow when a new request is submitted (usually "When an item is created" in a SharePoint list, or "When a new response is submitted" in Microsoft Forms).

Data enrichment that looks up additional context the approver needs: the requester's manager name, department, budget remaining, or any related records from other lists or systems.

The approval action itself using "Start and wait for an approval" configured with the right type (sequential, parallel, or first-to-respond), clear title, detailed description, and the correct assignee.

A condition check that evaluates the outcome: approved or rejected. Note that "Approve" is case-sensitive in Power Automate. This trips up more people than you'd expect.

Post-approval actions including status updates in the SharePoint list, notification emails or Teams messages to the requester, and any downstream triggers (like creating a record in another system).

Post-rejection actions including requester notification with the approver's comments, status update, and optionally a mechanism for the requester to revise and resubmit.

Error handling using "Configure run after" settings on critical actions so the flow doesn't silently fail when a connector times out or a lookup returns no results.

Audit logging that writes every approval decision (who approved, when, with what comments) to a SharePoint list or Dataverse table for compliance and reporting.

Choosing the right trigger for your scenario

The trigger determines when the flow starts running. Choosing the wrong trigger creates either false starts or missed requests. The most common triggers for approval workflows in the Microsoft 365 ecosystem:

"When an item is created" (SharePoint): The most common and most reliable trigger for business approval workflows. A user submits a request by adding a new item to a SharePoint list (either directly or through a Power App form). The flow triggers immediately. Use this when you have a structured request form with defined fields.

"When a new response is submitted" (Microsoft Forms): Good for simpler scenarios where the request is a straightforward form without complex data relationships. The flow triggers when someone submits a form. Use this for lightweight processes like event RSVP approvals or quick feedback requests. For anything involving amounts, document attachments, or multi-field requests, SharePoint lists are more robust.

"When a file is created or modified" (SharePoint): Triggers when a document is uploaded to a specific library. Use this for document approval workflows where the uploaded file itself is what needs reviewing (like contracts, proposals, or marketing materials).

"For a selected item" (SharePoint): A manual trigger. The user selects an item in a SharePoint list and clicks "Run flow" from the menu. Use this when the approval should only be initiated by a specific person (like a manager reviewing a batch of requests), not automatically on submission.

Smart routing: sending approvals to the right person based on conditions

The simplest approval flow sends every request to the same person. But in most real scenarios, the approver depends on the request. An expense under $5,000 goes to the department manager. Over $5,000 goes to the finance director. A leave request goes to the team lead. A procurement request goes to the procurement committee.

In Power Automate, this is handled with condition actions (if/else logic) or switch actions (for multiple branches). The condition evaluates a field in the request (like "Amount" or "Department") and routes to the appropriate approver.

For dynamic approver routing (where the approver is determined by the requester's position in the org chart), use the "Get manager" action from the Office 365 Users connector. This pulls the requester's direct manager from Azure Active Directory. The approval is then sent to that manager dynamically, without hardcoding any names. When someone changes managers, the flow automatically routes to the new manager. No flow editing required.

For multi-level approvals (manager, then director, then VP), chain multiple "Get manager" actions. The first gets the requester's manager. The second uses the manager's email to get the manager's manager. Each level gets its own "Start and wait for an approval" action in sequence.

Why Teams adaptive card notifications beat email for approvals

By default, Power Automate sends approval notifications via email. This works, but email is where approvals go to die. The notification lands in an inbox alongside 50 other emails. It gets read, mentally filed as "I'll handle this later," and forgotten. Three days pass. The requester sends a follow-up.

Microsoft Teams adaptive cards are dramatically better for approval response rates. The approval shows up as an interactive card directly in the approver's Teams chat. They can see the details, add a comment, and tap Approve or Reject without leaving Teams. No switching to email. No opening a link. No signing into the Power Automate action center. The decision happens in the tool they already have open all day.

To use Teams notifications, configure the "Start and wait for an approval" action with the approver's email address. Power Automate automatically sends both an email and a Teams notification. The approver can respond from either channel. For organizations that want Teams-only notifications (no email), you can disable the email notification in the approval action's advanced settings and use the "Post adaptive card and wait for a response" Teams action instead for full control over the card's appearance.

Building escalation logic that prevents bottlenecks

Every approval workflow needs an answer to this question: what happens when the approver doesn't respond? Without escalation, the request sits in limbo indefinitely. The requester waits. The process stalls. Nobody is accountable for the delay.

The escalation pattern: After the "Start and wait for an approval" action, add a parallel branch with a "Delay" action set to your escalation threshold (typically 24 or 48 hours). After the delay, send a reminder notification to the approver. If another 24 hours pass, send a second reminder with the approver's manager CC'd. If the total elapsed time exceeds your maximum (say, 72 hours), automatically reassign the approval to the next person in the chain or auto-approve based on policy.

The specific escalation policy depends on the process. Leave requests might auto-escalate after 24 hours. Procurement approvals over $25,000 might wait 72 hours with three reminders before escalating. The key is that every approval flow has a defined timeout behavior. "Wait forever" is not an acceptable design choice.

Logging every decision for audit trails and reporting

An approval workflow without audit logging is a process without memory. You know the current status of a request, but you can't answer: who approved it? When? With what comments? How long did it take? How many requests were rejected last quarter? Which approver is consistently the bottleneck?

The fix is simple: after every approval decision, write a record to a SharePoint list or update a log column on the original request. The log entry should capture the approver's name, the decision (approved or rejected), the timestamp, and any comments. For multi-level approvals, log each level separately.

Over time, this log becomes a goldmine for process improvement. If you connect it to Power BI, you can build dashboards showing average approval time by department, rejection rates by category, bottleneck identification by approver, and trend analysis over months. This transforms an approval workflow from an operational tool into a management intelligence system.

Mistake 1: No reminder for unresponsive approvers

This is the number one reason approval workflows lose trust. The flow sends the approval. The approver doesn't respond. Nothing happens. The request sits in limbo for days. The requester starts sending manual follow-up emails, defeating the entire purpose of automation. Always build escalation reminders at 24, 48, and 72 hours. Always.

Mistake 2: Hardcoding approver names instead of using dynamic lookup

The flow sends every expense approval to "john.smith@company.com" because John is the finance director. John gets promoted. The flow still sends to John. Nobody updates it for three weeks. Twenty expense reports are stuck. Use the "Get manager" action or a SharePoint lookup list that maps departments to approvers. When personnel change, update the lookup list. The flow adapts automatically.

Mistake 3: No feedback loop when a request is rejected

A rejection without explanation is a dead end. The requester knows their request was rejected but doesn't know why or what to change. They resubmit the same request. It gets rejected again. Frustration builds. Always include the approver's comments in the rejection notification. Better yet, add a "Resubmit" mechanism where the requester can revise the request and trigger a new approval cycle without creating a brand-new entry.

Mistake 4: Skipping the pilot test with real users

Building the flow in a development environment and testing with sample data is necessary but insufficient. The real test is having actual users submit actual requests through the production flow. They'll do things you didn't anticipate: leave fields blank, enter text where numbers should be, submit from mobile where the experience is different, and click approve before reading the details. A one-week pilot with 10 real users catches every edge case that sandboxed testing misses.

Mistake 5: No error handling

Power Automate flows fail. Connectors time out. API limits are hit. Lookup actions return no results because someone deleted a reference list item. Without error handling, the flow fails silently. The request shows "In Progress" forever. Nobody knows it's stuck. Use "Configure run after" on critical actions (set to run on "has failed" and "has timed out"). Add a "Send an email" action in the failure branch that notifies the flow admin with the error details. This transforms invisible failures into visible, actionable alerts.

Mistake 6: Building for the happy path only

The "happy path" is when everything works perfectly: the request is complete, the approver responds promptly, the decision is approved, and the downstream actions succeed. Production reality includes: incomplete requests, approvers on vacation, rejected requests that need revision, simultaneous submissions that create race conditions, and connectors that return unexpected data. A production-quality flow handles all of these gracefully. A demo-quality flow handles none of them.

Real use cases across departments

Finance: Expense approval with conditional routing. Expenses under $500 auto-approve. $500 to $5,000 go to the department manager. Over $5,000 require both manager and finance director approval (sequential). Each decision is logged. A Power BI dashboard shows monthly spend by department with approval rates and average processing time.

HR: Leave request with balance validation. Employee submits leave through a Power App. Power Automate checks the leave balance in a SharePoint list before routing for approval. If the balance is insufficient, the request is auto-rejected with an explanation. If sufficient, it routes to the team lead. Approved leaves automatically deduct from the balance. HR has a dashboard showing leave patterns across the organization.

Procurement: Vendor registration with multi-department approval. A new vendor registration requires parallel approval from Procurement (for commercial terms), Legal (for contract compliance), and IT (for data security). All three receive the request simultaneously. The vendor is registered only when all three approve. Any rejection returns to the requester with consolidated feedback from all reviewers.

IT: Service request with SLA tracking. An employee submits an IT service request. Power Automate assigns it to the right support team based on category (hardware, software, access, network). A timer starts for SLA tracking. If the request isn't acknowledged within 4 hours, it escalates. If not resolved within 24 hours, the IT manager is notified. Resolution data feeds into a Power BI dashboard showing resolution rates, average time, and recurring issue categories.

Operations: Document approval with version control. A policy document is uploaded to a SharePoint library. Power Automate routes it through a review chain: author → reviewer → approver. Each person can approve, reject with comments, or request revisions. The approved version is automatically published to the intranet. Previous versions are archived. The entire review history is logged for compliance.

The workflow that runs itself

A well-built approval workflow should be invisible. The requester submits and gets a confirmation. The approver receives a Teams notification, taps a button, and moves on with their day. The requester gets the outcome within hours, not days. The status is visible to everyone who needs to see it. The audit trail writes itself. Escalation handles itself. Exceptions are caught and reported automatically.

That's what Power Automate is built for. Not to replicate your email-based approval chain in a fancier interface, but to build a system that handles the entire lifecycle of a decision: submission, routing, notification, escalation, decision, logging, and downstream action. When it's built right, nobody thinks about the approval process anymore. It just works. And that's the highest compliment any automated workflow can receive.