Build an Amount-Based Approval Workflow in Power Automate

Most approval workflows start simple.

Someone submits a request.

A manager approves it.

The requester gets notified.

But in real businesses, approvals are rarely that simple.

A $50 software request may only need a manager’s approval.
A $2,000 equipment request may need both manager and finance approval.
A department-specific request may need a completely different approver.

That is where conditional approval routing becomes useful.

In this tutorial, I will show you the structure of an amount-based multi-level approval workflow in Power Automate.

The example use case is an expense or purchase request system, but the same logic can be reused for many other approval systems.

What we are building

We are building a purchase request approval system using:

• Microsoft Forms for request submission
• Power Automate for workflow logic
• Excel Online as the approval tracker
• Outlook email notifications for the final decision

The approval rule is simple:

If amount is under $500
→ Send to Manager only

If amount is $500 or more
→ Send to Manager first
→ If Manager approves, send to Finance
→ Then notify requester

This creates a practical multi-level approval workflow without SharePoint, premium connectors, or custom code.

Full video walkthrough

I recorded the complete step-by-step build here:

The rest of this article breaks down the logic so you can reuse the same pattern in different business automations.

The workflow architecture

At a high level, the flow looks like this:

Microsoft Form submitted
        ↓
Get response details
        ↓
Generate unique Request ID
        ↓
Add request to Excel tracker
        ↓
Send approval to Manager
        ↓
Check Manager decision
        ↓
If rejected:
    Update Excel
    Email requester

If approved:
    Check amount
        ↓
    If under $500:
        Update Excel
        Email requester

    If $500 or more:
        Send approval to Finance
        Check Finance decision
        Update Excel
        Email requester

This is not only an expense workflow.

It is a reusable approval pattern.

You can change the condition from amount to department, category, vendor, urgency, location, employee role, or any field from the form.

Microsoft Form fields

The form should collect all the information the approver needs to make a decision.

For this example, I used these fields:

The most important field here is Amount.

In Microsoft Forms, set it as a number field because Power Automate needs to compare it in a condition.

Excel approval tracker

The Excel file works as the approval log.

Every form submission creates a new row.
Then Power Automate updates the same row as the request moves through the approval stages.

Recommended columns:

Important: the Excel range must be formatted as a table.

Power Automate actions like “Add a row into a table” and “Update a row” need a proper Excel table. Plain cells are not enough.

Expression 1: Generate a unique request ID

Before adding the request to Excel, create a Compose action named:

Request ID

Use this expression:

guid()

This generates a unique ID for every submission.

Why is this important?

Because later in the flow, you need to update the exact same row in Excel after the manager or finance approver responds.

Without a unique key, updating the correct row becomes risky.

Expression 2: Convert amount to a number

Form responses often behave like text in Power Automate.

So before comparing the amount, convert it to an integer:

int(outputs('Get_response_details')?['body/Amount'])

Your dynamic content name may be different, but the idea is the same.

You are telling Power Automate:

Treat this form value as a number, not text.

Then the condition becomes:

Amount is greater than or equal to 500

This condition controls the approval path.

Manager approval

The first approval goes to the manager.

Use:

Start and wait for an approval

Approval type:

First to respond

The approval title can include the item and amount, for example:

Purchase request for Laptop - $850

In the approval details, include the full request information:

Requester Name:
Department:
Amount:
Item:
Vendor:
Business Justification:
Needed by Date:

This makes the approval email useful. The manager should not need to open another file just to understand the request.

Check manager decision

After the manager approval action, add a Condition.

Check:

Outcome is equal to Approve

Be careful here.

In Power Automate approvals, the outcome is usually:

Approve

Not:

Approved

That small wording mistake can break the logic.

If manager rejects

If the manager rejects the request:

1. Update the Excel row
2. Set Manager Decision to Rejected
3. Save the manager comment
4. Save the completion timestamp
5. Set Status to Manager Rejected
6. Send an email to the requester

Example requester email:

Subject:
Your purchase request for [Item] has been rejected

Body:
Hi [Requester Name],

Unfortunately, your purchase request has been rejected.

Amount: [Amount]
Item: [Item]
Vendor: [Vendor]

Manager's Comment:
[Manager Comment]

Thank you.

This keeps the requester informed and keeps the Excel tracker accurate.

If manager approves

If the manager approves, the flow checks the amount.

If the amount is under $500:

1. Update the Excel row
2. Set Manager Decision to Approved
3. Save manager comment
4. Save manager timestamp
5. Set Status to Approved by Manager
6. Email the requester

No finance approval is needed.

If the amount is $500 or more, the flow continues to Finance.

Finance approval

For $500+ requests, add a second approval action.

The Finance approval should include the original request details and the manager’s comment.

That is important because Finance should see the business context and the manager’s reason for approving it.

Finance approval details can include:

Requester Name:
Department:
Amount:
Item:
Vendor:
Business Justification:
Needed by Date:

Manager's Comment:
[Manager Comment]

Then add one final condition:

Finance Outcome is equal to Approve

If Finance approves:

• Update Finance Decision to Approved
• Save Finance Comment
• Save Finance Timestamp
• Set Status to Fully Approved
• Send approval email to requester

If Finance rejects:

• Update Finance Decision to Rejected
• Save Finance Comment
• Save Finance Timestamp
• Set Status to Finance Rejected
• Send rejection email to requester

Why this pattern is reusable

This tutorial uses an expense request system, but the structure is more powerful than that.

You can reuse the same logic for:

The core pattern stays the same:

Collect request
Save request
Send approval
Check decision
Check routing condition
Send next approval if needed
Update tracker
Notify requester

Once you understand that pattern, you can build many approval systems from the same foundation.

Common mistakes to avoid

1. Forgetting to format Excel as a table

Power Automate needs the Excel data formatted as a table. If you only have column headers in plain cells, the Excel actions will not work properly.

2. Not using a unique Request ID

Use guid() and store the value in Excel. Then use that same value as the key when updating the row.

3. Comparing amount as text

Use int() before comparing numbers from Microsoft Forms.

4. Using “Approved” instead of “Approve”

The approval outcome is usually Approve. Check the exact value from your approval action.

5. Not saving comments

Approver comments are important. They explain why a request was approved or rejected.

6. Sending vague email notifications

Do not only say “Your request was approved.”

Include the item, amount, vendor, and comments so the requester understands the decision.

Final thoughts

This is one of my favorite Power Automate patterns because it is practical.

It is not just a demo flow.

It solves a real business problem:

• employees submit requests in a structured form
• approvers get clear approval emails
• decisions are tracked in Excel
• comments and timestamps are saved
• requesters are automatically notified
• the approval path changes based on the request data

You can start with the expense request version and then adapt the same logic for PTO requests, IT approvals, software access requests, procurement workflows, or document approvals.

The complete build is shown in the video above.

If you are building something similar, I would start with the amount-based version first, then modify the condition once the basic flow is working.