How to Build an Approval Workflow in Power Automate - A Practical Build Guide
Approval workflows are the most common reason businesses buy Power Automate. They are also where most implementations quietly fall over after a few months of use. The basic flow is easy. Building one that actually stands up to real use, with edge cases handled and humans behaving the way humans behave, is a different exercise.
This is the build guide I would hand to a developer or business analyst starting their first serious approval automation. I have been building these flows for clients across financial services, professional services and manufacturing since 2021. The patterns here are the ones that have survived contact with real users.
What an Approval Workflow Actually Needs
Before drawing boxes and arrows, think about what your approval needs to do beyond the happy path.
Who can approve? Just one person, or any of several? Does it depend on amount, department, or risk level?
What happens if the approver is on leave? Does the request sit there until they return, or does it escalate?
What happens if the approver rejects? Does the requestor get told why? Can they resubmit?
Do you need an audit trail that finance or compliance will eventually ask for? In Australia, especially in financial services or healthcare, the answer is almost always yes.
What does the system do at the end? File a record, update a system, push to ERP, send a confirmation?
If you cannot answer those five questions before you open Power Automate, you are not ready to build yet. I have seen too many flows that work for the demo and break the moment a real request comes through with a delegated approver or a multi-line cost code.
The Core Build - A Single-Stage Approval
Start with the simplest version and add complexity as needed. The single-stage approval is the foundation everything else builds on.
The trigger varies depending on where requests come from. The common ones in our work are SharePoint list item created, Forms response submitted, Outlook email arrived, or Teams adaptive card submitted. For internal HR or finance requests, a SharePoint list with a custom form is usually the cleanest starting point because it gives you a structured store of the request plus a place to write the outcome back.
After the trigger, the flow needs three things in order.
First, build a clear approval payload. The Approvals action in Power Automate accepts a title, details (markdown), and the approver email. Spend time on the details field. Put every piece of information the approver needs to make a decision in there. Do not make them open a separate document or jump into another system to check what they are approving. We have seen approval rates and response times improve dramatically just by including all relevant context in the approval card itself.
Second, choose the right approval type. "Approve/Reject - First to respond" is for when any of several approvers can decide. "Approve/Reject - Everyone must approve" is for sequential or parallel multi-approver workflows. "Custom Responses - Wait for all responses" is for when you need more than just yes or no, like "Approve", "Approve with conditions", "Reject", or "Request more information."
Third, handle the response. Use a Switch action on the outcome field. Branch into Approved, Rejected, and any custom responses. In each branch, do the actual work - update the SharePoint item, send notifications, push to the downstream system, log the decision.
A common mistake is putting all the post-approval logic in a single condition with nested conditions. Use a Switch. Your flow will be readable in six months. Nested conditions will not be.
Adding Multi-Stage Approval
Single-stage works for simple requests. Most real business processes have at least two stages - line manager approves, then department head approves, then maybe finance approves above a certain amount.
The clean pattern is one Approval action per stage, with conditions in between that decide whether the next stage is required. Do not chain ten approvals together unconditionally. Most requests should skip most stages.
A pattern we use in finance approval flows for Australian businesses:
Stage 1 - Line manager approves all requests. Stage 2 - Department head approves anything over AUD 5,000. Stage 3 - CFO approves anything over AUD 25,000. Stage 4 - CEO approves anything over AUD 100,000.
Each stage is a separate Approval action gated by a condition on the request amount. If a request comes in for AUD 800, only Stage 1 runs. If it comes in for AUD 50,000, three stages run sequentially.
Between stages, send a status update to the requestor. People want to know where their request is. Silent approvals create the wrong kind of follow-up emails.
Parallel Approvers and Branches
Sometimes you need multiple people to approve in parallel, not in sequence. Two department heads sign off independently, then if both agree, the request proceeds.
Power Automate supports this directly with "Everyone must approve" mode and a list of approvers. The action will not complete until every approver has responded.
The gotcha is what happens if one of the parallel approvers is on leave. The whole flow stalls. For parallel approvals, you almost always need to combine this with delegation logic, which we cover below.
For parallel branches that are genuinely independent - like an IT security approval running alongside a finance approval - use Parallel Branches in the flow itself rather than a single approval action with multiple approvers. Each branch can have its own approval, its own timeout, its own escalation. After both branches complete, a join condition decides whether to proceed.
The Delegation Problem
This is where most approval workflows fall over in practice. People go on leave. They go to conferences. They get promoted and no longer hold the approval responsibility. Your beautiful flow stops dead because the email it sent to [email protected] is sitting in a mailbox that nobody reads for two weeks.
There are three patterns for handling this, in increasing order of reliability.
The first is "out of office" detection. Before sending an approval, query the approver's Outlook calendar for "out of office" status. If they are away, route to their delegate. This works if your organisation has discipline around setting out-of-office messages, which most do not.
The second is a delegation table in SharePoint or Dataverse. Each approver maintains their own delegates for given date ranges. The flow checks the table at runtime. This is more work to set up but much more reliable. The delegate has explicit authority and the audit trail shows it clearly.
The third is escalation timeouts. If an approval is not actioned within X hours, escalate to the next person up the chain. Combined with delegation, this catches the cases where the delegate is also unavailable.
For mission-critical approvals - leave requests, payment authorisations, contract sign-offs - use both delegation and escalation. We have built flows where finance approvals escalate from manager to department head after 24 business hours, then to CFO after another 48 hours. The escalation rarely fires, but when it does, it has saved real business outcomes.
Teams Integration
Most Australian businesses we work with want approvals to land in Teams, not email. The Teams adaptive card approval is the right pattern for this.
The Approvals action in Power Automate already integrates with Teams - approvers see the request in the Teams Approvals app and can action it without leaving Teams. For most use cases, this is sufficient.
For higher-engagement scenarios, post an adaptive card directly to a Teams channel or chat. The approver can approve, reject, or add a comment from within the chat itself. This works well for requests that benefit from group visibility, like project change requests or marketing creative approvals.
A small but useful pattern - when an approval is completed, post an update to the same channel showing the outcome. It closes the loop and gives the team awareness of decisions without anyone having to ask.
The Audit Trail Question
Auditors will eventually ask for proof of who approved what, when, and why. Power Automate's approval history is not enough on its own because retention is limited and querying it is awkward.
Build your own audit log. After every approval decision, write a row to a SharePoint list or Dataverse table with the request ID, approver, decision, timestamp, comments, and the full approval payload. This becomes your authoritative record. For regulated industries like financial services or healthcare, the auditors will want this anyway.
For seven-year retention requirements, which apply to many financial records in Australia, plan storage accordingly. SharePoint can handle the volume for most businesses. For high-volume environments, push the audit records to Azure Storage or a Dataverse table with proper archival policies.
Cost Considerations
Approval workflows themselves do not cost much to run if you build them in Cloud Flows under a Power Automate Premium licence. The user-level licence runs around AUD 24 per user per month, and that user is the flow owner, not every approver. Approvers can interact with approvals through the standard Microsoft 365 licence.
The cost trap is per-flow plans for high-volume flows, or accidentally using Premium connectors that nobody costed for. If your approval flow needs to talk to SAP, Salesforce, or any non-Microsoft enterprise system through a Premium connector, you need either per-flow licensing (around AUD 160 per flow per month) or per-user Premium licences for the flow owner.
For a typical Australian mid-market business running ten to twenty approval flows on Microsoft connectors, the licensing impact is small. For an enterprise with hundreds of flows hitting Premium connectors, the maths needs more attention.
For detailed pricing scenarios, see our Power Automate licensing guide for Australia.
A Decision Framework for Build vs Configure
Not every approval needs to be built in Power Automate. Sometimes the simpler option is to use what is already there.
| Scenario | Best fit |
|---|---|
| Simple leave approvals, single manager | Microsoft Planner, Outlook delegated approvals, or Power Automate basic flow |
| Multi-stage financial approvals with audit trail | Power Automate Cloud Flow with custom audit log |
| Approvals tightly coupled to a SaaS app you already use | Native approval feature in the SaaS app, if it exists |
| Approvals across multiple business systems | Power Automate as the orchestrator |
| Approvals requiring complex business rules and external data | Custom solution or Power Automate plus Power Apps front end |
| High-volume programmatic approvals (thousands per day) | Custom build, not Power Automate |
The reason this matters is that we have seen clients put genuine effort into building approval flows in Power Automate when the system they were approving against had a perfectly good approval mechanism already. Use what is there. Build only what you have to.
Common Mistakes to Avoid
A few patterns I have seen go wrong enough times to mention.
Putting business logic in expressions is brittle and unreadable. Use variables and conditions. Expressions like if(and(greater(triggerBody()?['amount'], 5000), equals(triggerBody()?['department'], 'Finance')), ...) will be impossible for anyone else to maintain.
Hardcoding approver emails. Always pull approvers from a configuration list or from a user property like the manager field in Azure AD. People change roles. Your flow should not require code changes when that happens.
No error handling. Power Automate flows fail. APIs time out, users get deleted, SharePoint lists get renamed. Wrap critical steps in scope blocks with "Configure run after" set to handle failures gracefully. At minimum, send the flow owner a notification when something breaks.
No idempotency. If the flow runs twice for the same request because of a retry, what happens? Probably duplicate approvals. Build in a check at the start that looks for an existing approval for that request ID and exits if one exists.
No timeout on approvals. The default timeout is 30 days. For business-critical approvals, set a shorter timeout and define what happens on timeout. Otherwise your flow sits in pending for a month and nobody notices.
When to Bring in Consulting Help
A single-stage approval flow with one approver and a SharePoint trigger is something a competent business analyst can build in a day or two with practice. You probably do not need a consultant for that.
Where consulting help pays off is when the requirements include any of - multi-stage approvals with conditional routing, delegation and escalation logic, audit trail for regulated industries, integration with line-of-business systems beyond Microsoft 365, high volume or critical-path workflows where failure is expensive, or governance and DLP setup across many flows.
We typically come in at the design stage on these projects, sketch out the architecture, then either build the first version with you or hand the design to your internal team to build. A two-week consulting engagement usually pays for itself many times over by avoiding the rebuild that happens when the first attempt does not survive contact with real users.
If you are building approvals for a regulated industry or as part of a broader business process automation programme, our Power Automate consulting practice handles design, build and handover. For the wider workflow automation picture, our work on AI process automation covers the patterns for combining approvals with AI agents and intelligent document processing.
Approval workflows look simple. They are not. Build the first one carefully and the rest become much easier. Get in touch if you want a second opinion on your approval architecture before you commit to a build.