Back to Blog

How to Build an Approval Workflow in Power Automate

April 15, 2026•11 min read•Michael Ridland

Approval workflows are the bread and butter of Power Automate implementations. Nearly every business has processes where someone needs to approve something before it moves forward - purchase requests, leave applications, document sign-offs, expense claims, project proposals. These approvals are simple in concept but surprisingly time-consuming when handled manually through email chains.

We've built approval workflows for organisations across Australia, from simple single-approver flows to complex multi-level approval chains with conditional routing, delegation, and escalation. Here's how to do it properly.

Why Approval Workflows Matter

Before getting into the build, let's be clear about the problem. Manual approval processes typically suffer from:

  • Slow turnaround. Approval requests get buried in email inboxes. We've seen purchase requests sit for two weeks because the approver missed the email.
  • No visibility. The person who submitted the request has no idea where it is in the process. They send follow-up emails, which create more noise.
  • No audit trail. When auditors ask "who approved this and when?", the answer is somewhere in an email chain that might have been deleted.
  • No delegation. When the approver is on leave, requests pile up. Nobody knows who to ask instead.
  • Inconsistent routing. Different amounts go to different approvers, but this routing logic lives in someone's head, not in a system.

A well-built approval workflow in Power Automate fixes all of these.

The Building Blocks

Power Automate has built-in approval actions that handle the core mechanics. Here's what you're working with:

Approval actions:

  • Start and wait for an approval (pauses the flow until someone responds)
  • Create an approval (creates it without waiting - useful for parallel approvals)
  • Wait for an approval (waits for a previously created approval)

Approval types:

  • Approve/Reject - everyone must approve (unanimous)
  • Approve/Reject - first to respond (anyone can approve or reject)
  • Custom responses - you define the response options

Notification channels:

  • Email (automatic - Power Automate sends an approval email)
  • Microsoft Teams Adaptive Cards (our recommended approach)
  • Power Automate mobile app

Building a Single-Level Approval Workflow

Let's start with the simplest case: a purchase request that needs one person's approval.

Step 1 - Create the Request Form

Use Microsoft Forms or a SharePoint list to capture the request. For a purchase request, you need:

  • Requester name (auto-populated)
  • Description of what's being purchased
  • Amount (AUD)
  • Vendor/supplier
  • Cost centre or department
  • Reason for purchase
  • Supporting documents (attachments)

Tip: Use a SharePoint list rather than Forms if you want the requests to persist and be searchable. Forms responses are harder to query later. We usually create a SharePoint list called "Purchase Requests" with columns for each field plus status columns (Pending, Approved, Rejected).

Step 2 - Build the Flow

Create an automated cloud flow triggered by "When an item is created" in your SharePoint list.

Configure the approval action:

  • Approval type: Approve/Reject - First to respond
  • Title: "Purchase Request: [Description] - $[Amount]"
  • Assigned to: The approver's email address
  • Details: Include all the request details so the approver has everything they need without opening another application
  • Item link: Link back to the SharePoint list item

What to include in the approval details:

The approval notification should contain everything the approver needs to make a decision. In our experience, the most common reason approvals stall is that the approver needs to look up additional information. Include:

  • What's being purchased and why
  • The amount and budget context (e.g., "This is 15% of the remaining Q2 marketing budget")
  • Who's requesting it
  • Any supporting documents or quotes
  • Historical context if relevant (e.g., "This vendor was used for our last three projects")

Step 3 - Handle the Response

After the approval action, add a condition to check the response:

If Approved:

  • Update the SharePoint list item status to "Approved"
  • Send a notification to the requester: "Your purchase request for [Description] ($[Amount]) has been approved by [Approver]"
  • Optionally trigger the next step in your procurement process
  • Log the approval with timestamp and approver name

If Rejected:

  • Update the SharePoint list item status to "Rejected"
  • Send a notification to the requester including the rejection reason (require approvers to provide comments when rejecting)
  • Log the rejection with timestamp, approver name, and reason

Step 4 - Add Timeout Handling

This is where many implementations fall short. What happens if the approver doesn't respond?

Configure a timeout on the approval action (e.g., 48 hours for purchase requests). When the timeout triggers:

  • Send a reminder to the approver
  • Optionally escalate to their manager
  • Update the status to "Escalated"
  • Notify the requester that the request has been escalated

Building a Multi-Level Approval Workflow

Most real-world approvals need more than one level. Here's how to build a tiered approval based on amount:

Approval Routing Logic

Amount (AUD) Approval Level 1 Approval Level 2 Approval Level 3
Under $1,000 Direct Manager - -
$1,000 - $10,000 Direct Manager Department Head -
$10,000 - $50,000 Direct Manager Department Head CFO
Over $50,000 Direct Manager Department Head CFO + CEO

Implementation Approach

Step 1: After the request is created, use a Switch action (or nested conditions) based on the amount to determine the approval path.

Step 2: For each path, chain approval actions sequentially. The second approval only triggers if the first is approved.

Step 3: At each level, if the request is rejected, the flow stops, the requester is notified, and the status is updated. No need to send it up the chain.

Step 4: For the "CFO + CEO" level, use the "Everyone must approve" approval type, which requires both to approve.

Dynamic Approver Assignment

Hard-coding approver email addresses into flows is a maintenance headache. When someone changes roles or leaves, you need to update every flow. Instead:

Option 1 - SharePoint lookup list. Create a SharePoint list that maps departments to approvers at each level. The flow looks up the approver dynamically based on the requester's department. When someone changes roles, you update the list, not the flow.

Option 2 - Azure AD/Entra ID manager lookup. Use the Office 365 Users connector to get the requester's manager from Entra ID (formerly Azure AD). This automatically routes to the correct manager without any static configuration.

Option 3 - Combination. Use Entra ID for Level 1 (direct manager) and a SharePoint lookup for higher levels (department head, CFO, CEO). This is our recommended approach for most organisations.

Teams Integration - Our Recommended Approach

We always recommend Teams Adaptive Cards as the primary approval interface. Here's why and how:

Why Teams Over Email

  • Faster response times. People check Teams more frequently than email during the work day. We've measured 40-60% faster approval times with Teams vs email.
  • Richer information. Adaptive Cards can display structured data, images, and interactive elements that email can't.
  • Mobile friendly. Teams mobile app renders Adaptive Cards well, so approvers can review and approve from their phone.
  • Conversation context. If the approver has a question, they can reply in Teams rather than starting a separate email thread.

Building the Adaptive Card

Instead of using the default approval notification, build a custom Adaptive Card that includes:

  • A clear header with the request type and amount
  • Key details in a structured layout (not a wall of text)
  • A link to view attachments or the full request in SharePoint
  • Approve and Reject buttons
  • A required comments field (especially for rejections)

Practical tip: Keep the card concise. Approvers are busy. Put the decision-critical information at the top and supporting details below. The approver should be able to make a decision in 30 seconds without scrolling.

Delegation and Out-of-Office Handling

This is where approval workflows go from "nice to have" to "production ready." Every approval system needs to handle the reality that approvers take leave, get sick, and travel.

Approach 1 - Automatic Delegation

Check the approver's calendar or out-of-office status before routing. If they're away:

  • Route to their designated delegate (maintained in a SharePoint list)
  • Or route to their manager (looked up from Entra ID)
  • Notify both the original approver and the delegate

Approach 2 - Timeout-Based Escalation

Send the approval to the original approver. If no response within a defined period (e.g., 24 hours), escalate:

  1. First escalation: Send a reminder to the approver
  2. Second escalation (e.g., 48 hours): Route to their manager with a note that the original approver hasn't responded
  3. Final escalation (e.g., 72 hours): Route to a department administrator

Approach 3 - Parallel Routing

Send the approval to both the primary approver and their delegate simultaneously. First to respond wins. This is the simplest approach and works well when you have two people who can both legitimately approve.

Our recommendation: Use Approach 1 for planned absences and Approach 2 as a safety net. This covers both planned leave and unexpected unavailability.

Parallel Approvals

Some workflows require multiple people to approve simultaneously rather than sequentially. For example, a project proposal might need approval from both the finance director and the technical director.

How to implement:

  1. Use the "Create an approval" action (not "Start and wait") to create both approvals without waiting
  2. Use two "Wait for an approval" actions in parallel branches
  3. After both branches complete, check if both were approved
  4. Only proceed if all required approvals are received

Important: Configure timeout handling for each parallel approval independently. If one approver responds quickly but the other is slow, you don't want the fast approver's decision to expire.

Common Approval Workflow Patterns for Australian Businesses

Expense Claim Approval

Trigger: Employee submits an expense claim via SharePoint/Power Apps Validation: Check against expense policy (meal limits, accommodation rates, receipt requirements) Routing: Direct manager for all claims, finance team for claims over $500 Post-approval: Create entry in accounting system, schedule reimbursement Australian-specific: GST validation on receipts, FBT flagging for certain expense types

Document Approval

Trigger: Document uploaded to a SharePoint library or status changed to "Ready for Review" Routing: Document owner's manager, then department head for policy documents Post-approval: Move document to "Published" library, notify stakeholders, update version Useful feature: Use Power Automate's "Request sign-off" to get formal sign-off with digital signatures

Vendor Onboarding Approval

Trigger: New vendor request submitted via Forms Validation: Check ABN against ABR, check for existing vendor record, verify insurance details Routing: Procurement manager, then finance director for high-value vendors Post-approval: Create vendor record in accounting system, send welcome pack to vendor

IT Access Request

Trigger: Employee or manager submits an access request Routing: IT security team, then data owner for sensitive systems Post-approval: Provision access (can be automated with further Power Automate flows or integration with identity management) Compliance: Log access grants for audit purposes

Testing Your Approval Workflow

Testing approval workflows requires more thought than testing simple automations. Here's our testing checklist:

Functional testing:

  • Submit a request and verify the correct approver receives it
  • Approve and verify the correct post-approval actions fire
  • Reject and verify the correct post-rejection actions fire
  • Test with amounts at each threshold boundary ($999, $1,000, $1,001)
  • Test with different requesters from different departments

Edge case testing:

  • What happens if the approver's email is invalid?
  • What happens if the approval times out?
  • What happens if the same person submits two requests simultaneously?
  • What happens if the approver is also the requester?
  • What happens if there's a network error during the approval action?

User acceptance testing:

  • Have actual approvers test the flow and provide feedback on the notification format
  • Verify the mobile experience (Teams Adaptive Cards on phone)
  • Confirm the approval details contain enough information to make a decision

Performance Considerations

For organisations processing many approvals, keep these in mind:

  • Flow run limits. Power Automate has daily flow run limits based on your license. For high-volume approval workflows, ensure your license supports the volume.
  • Approval response time. The "Start and wait for an approval" action can wait up to 30 days. For approvals that might take longer, build a reminder and resubmission mechanism.
  • SharePoint throttling. If your approval flow reads and writes to SharePoint heavily, you may hit SharePoint API throttling limits. Use batching and caching where possible.

Getting Started

If you want to implement approval workflows for your business and want them done right the first time, talk to our team. We've built approval systems for organisations across Australia and we know where the edge cases hide.

Explore our Power Automate consulting services, learn about our broader automation capabilities, or see how we approach business automation for Australian organisations.