Power Automate Approval Flow: Stop Chasing Sign-Offs

Before you touch Power Automate, build a SharePoint list to hold the purchase requests. Columns matter here. At minimum you want: Requester, Vendor, Amount, Description, Status (choice column: Pending/Approved/Rejected), Approver Comments, and Date Decided. This list becomes your single source of truth — not the inbox, not a shared Excel file that three people have open at once.

Once the list exists, create a flow triggered by "When an item is created" in that SharePoint list. This is cleaner than a form-based trigger because anyone in the department can add a request without learning a new tool, and the list itself becomes your audit log automatically.

The core action you want is Start and wait for an approval, not the older "Create an approval" action. Start and wait pauses the flow until someone responds, which means you can build logic after the approval step — updating the SharePoint item, sending a notification, kicking off a purchase order in your accounting system — without worrying about race conditions. Microsoft's own documentation on getting started with approvals walks through the basic setup, but the configuration choices are where most people get stuck.

When you add the action, you'll pick an approval type. For a single purchase order, "Approve/Reject - First to respond" or "Approve/Reject - Everyone must approve" are your two realistic options if more than one person needs to weigh in. For a single approver — say, anything under $1,000 goes straight to the department head — just assign one person and skip the complexity entirely.

Add a Condition action before the approval step that checks the Amount column. Route anything under a threshold to a single approver, and anything above it to a two-person chain. This is the piece that turns a flat approval into something that actually matches how your business spends money.

Sequential vs. first-to-respond: pick based on who needs to see it, not just speed

This is the decision point that trips up most builders. Sequential approvals send the request to one approver, wait for a decision, then pass it to the next person in line — useful when a department head needs to approve before finance ever sees the request. First-to-respond sends to everyone simultaneously and moves forward as soon as one person acts, which is faster but means your CFO might approve something your operations manager would have flagged.

Microsoft's guide on sequential modern approvals covers the technical setup, but the business decision comes first: if the approval chain represents a real chain of authority (department head, then finance, then ownership for large purchases), use sequential. If you just need any one of three managers to sign off quickly because they're interchangeable for that decision, first-to-respond gets things moving faster. Mixing the two patterns in the same flow — sequential for tier one, first-to-respond for a backup pair at tier two — is also doable with nested approval actions, and it's a pattern we build often for clients with multiple locations.

A lot of flows get built with a happy path and nothing else. The approval gets rejected, and the flow just... stops. Nobody tells the requester why, and they end up emailing the approver directly anyway, which defeats the entire point.

After the Start and wait for an approval action, add a Condition that checks the outcome. On the Approve branch, update the SharePoint item's Status column to "Approved," write the approver's comments into the Approver Comments field, and send a confirmation email or Teams message to the requester. On the Reject branch, do the same thing but pull the rejection comments and make sure they're visible — most rejections happen because of a missing vendor quote or a budget code issue, and if the requester can see the exact comment, they can fix it and resubmit without a phone call.

It's worth adding a "resubmit" path too. Rather than forcing someone to create a brand-new list item, let the flow check if Status equals "Rejected" and allow an edit to retrigger the approval when the requester updates the item. This keeps your list from filling up with duplicate entries for the same purchase.

This is the part office managers forget until someone asks for it. The SharePoint list itself is your audit trail if you build the flow to write back to it consistently — approver name, decision, timestamp, and comments all land in columns on the original item. Power Automate's run history also keeps a record of every flow execution, including who approved what and when, for a retention period you control in your environment's data policies.

For anything touching vendor payments or financial controls, don't rely on run history alone — it's meant for troubleshooting, not long-term compliance storage. Export or archive the SharePoint list on a schedule, or write the decision data to a Dataverse table if you're already using the Power Platform for other automations. If your business handles any regulated data alongside purchasing — healthcare vendors, for example — this kind of documented decision trail also supports the broader governance work most HIPAA and FTC Safeguards Rule programs require anyway.

A purchase approval flow is usually the first thing a Texas business builds in Power Automate, and it's a good starting point because the ROI is obvious within a week. But it rarely stays the only automation for long. Once people see requests moving without email chains, they start asking for the same treatment on vendor onboarding, PTO requests, and contract renewals. If you're building more than one or two flows, it's worth thinking about governance up front — who can edit flows, how connections are managed, what happens when the person who built the flow leaves the company. That's the kind of planning we help with under Power Platform governance and broader business automation engagements, and it saves a lot of headaches down the road.

If your team is juggling several manual approval processes and the one-off flows are starting to feel fragile, that's usually a sign it's time for a structured look at your automation strategy rather than another patchwork fix. Pairing this with your existing Microsoft 365 environment also means fewer licensing surprises and better alignment with your existing security posture.

Do I need Power Automate Premium for an approval flow?

Basic approval flows built on SharePoint and Office 365 connectors typically run on the standard license included with most Microsoft 365 business plans. Premium becomes necessary once you add premium connectors — Dataverse, SQL Server, or third-party accounting integrations — so check your licensing before promising stakeholders a fully integrated system.

Can I set an approval to time out if nobody responds?

Yes. The Start and wait for an approval action lets you combine it with a Timeout parameter or run it in parallel with a Delay action and a condition, so you can escalate to a backup approver if the primary approver hasn't responded within, say, 48 business hours.

What's the difference between the Approvals app and the Start and wait for an approval action?

The Approvals app in Teams and Outlook is the front-end interface approvers use to see and act on requests. Start and wait for an approval is the flow action that creates those approval requests and pauses execution until a response comes back. You'll use both — the action generates the request, and the app is where your approver actually clicks Approve or Reject.

How do I handle approvals for purchases above a certain dollar threshold differently?

Add a Condition action right after your trigger that checks the Amount field against your threshold values, then branch into separate Start and wait for an approval actions — one for low-dollar single-approver requests, another for high-dollar sequential or multi-approver chains. This is the single most useful pattern for purchase approval flows and it only takes one extra condition block to set up.

If chasing sign-offs by email is still how your office runs purchasing, PTO, or vendor approvals, the fix is usually a few hours of flow-building, not a software overhaul. Request a free IT assessment and we'll look at what's eating your team's time and whether a Power Platform build makes sense, or contact us to talk through your specific approval process.