Building an Approval Workflow in Power Automate — Digitizing Paper and Email-Based Approval Requests

“We print the approval form, stamp it, pass it to the next department, and it comes back a week later.” “We email an Excel request form as an attachment, and approval is a reply that says ‘OK.’” Companies that have already adopted Microsoft 365 come to us with this kind of request-and-approval headache all the time.

Power Automate has a dedicated mechanism called Approvals, and it’s often possible to build an approval workflow — where all the approver has to do is press a button in Teams or Outlook — entirely within a license you already have, at no extra cost. But there’s a gap between “the first flow runs” and “this can be trusted to run the business day-to-day.” Where do the approval records actually end up? What happens if the approver just leaves it sitting there? Who fixes the flow when the person who built it leaves the company? This article works through the basic building blocks of an approval flow, the design points that trip people up in practice, and where to draw the line on what Power Automate should — and shouldn’t — be doing.

1. The Bottom Line First

• Power Automate’s approval mechanism is built around the “Start and wait for an approval” action. You can choose from five approval types: “everyone must approve,” “first response,” “custom responses (everyone/one person),” and “sequential.”¹
• Approvers can respond from Teams, Outlook, the Power Automate portal, or the mobile app. There’s almost no need for anyone to learn a new screen just to approve something.²³
• For the request intake, Microsoft Forms, a SharePoint list, or Teams’ Approvals app are the three realistic options. If you’ll want to list and tally requests later, building around a SharePoint list is the standard, safe choice.
• A flow’s run history is visible for only 28 days by default, and a single run times out after at most 30 days. Don’t rely on run history for an approval audit trail — build in a design from the start that writes the result back to a SharePoint list or similar.⁴⁵
• The owner of the flow leaving or transferring is the single biggest operational risk to an approval flow. Set up co-owners and understand how connections are handled on the very day the flow goes live.⁶
• If you try to implement multi-stage approvals with heavy branching, delegated decision-making, or strict audit requirements exactly as written in a formal approval regulation, Power Automate stops being maintainable. That’s the territory of a dedicated workflow system or a custom-built solution.

2. What’s Actually Wrong With Paper and Email Approvals

What makes paper approval forms and email-attached Excel approvals painful isn’t the effort itself so much as the fact that you can’t see the status. When we talk to clients about this, it usually comes down to the same three things.

• You don’t know where it’s stuck right now. The requester has no way of knowing whose desk the approval form is sitting on, or which inbox the email got buried in. Following up means a phone call or a face-to-face nudge, which isn’t pleasant for whoever’s on the receiving end either.
• The records are scattered. The trail of who approved what ends up split between a paper filing cabinet and individual mailboxes. When you need to investigate “who approved that request, and when” for an audit or a later inquiry, you end up digging through someone’s mailbox — and if that person leaves the company, the whole mailbox disappears with them.
• Rejections are hard to trace. When a rejection or a request for revision happens verbally or by email, it gets muddled which version of the request the feedback was actually about. Resend a revised version, and the whole thing circulates from scratch again.

Nearly all of this is solved simply by bringing the request’s status and its record together into one place. And if you’ve already adopted Microsoft 365, you already have the place to put it (SharePoint), the notification channel (Teams/Outlook), and the automation (Power Automate) sitting right there.

3. The Basic Building Blocks of a Power Automate Approval

The “Start and Wait for an Approval” Action

The heart of an approval flow is the Approvals connector’s “Start and wait for an approval” action. Specify the approval request’s title, details, and approvers, and the flow pauses there, waiting for the approver’s response before moving on to the next action.¹

There are five approval types.¹

Using custom responses, you can define options like “Approve,” “Return,” “Hold” instead of a plain “approve/reject” pair — this becomes a building block for the rejection loop described later.

Note that using the approval feature requires a Microsoft Dataverse database. Records of approval requests and responses are stored in Dataverse, and in the default environment this is provisioned automatically the first time you create an approval flow, so you can usually start without ever thinking about it. The Approvals connector is a standard connector, so a license that includes standard connectors (such as Office 365) is enough to build an approval flow.¹

Where Approvers Respond From

Approval requests reach the approver by email and through the Power Automate mobile app.³ In Outlook, they arrive as a nicely formatted approval email that lets you respond directly.⁷ An approval directed at an individual user is also notified in Teams, where you can approve, reject, or add a comment from a chat or the Approvals app.² Not having to make anyone log in to a dedicated site just to approve something is the single biggest reason approval flows actually stick once adopted.

One thing to watch out for: if the approval is directed at a Microsoft 365 group, no Teams notification is sent. Teams notifications only go out for approvals directed at an individual user.⁸

The Overall Shape of the Flow

Using a purchase request as an example, the overall shape looks like this.

flowchart TD
    Submit[Requester submits<br/>Forms response / new SharePoint list item] --> Trigger[Cloud flow triggers<br/>on new response / item added]
    Trigger --> Record[Record the request in the<br/>SharePoint list, status: Pending approval]
    Record --> Approval[Start and wait for an approval<br/>request sent to approver]
    Approval -- Teams / Outlook / mobile --> Response{Response}
    Response -- Approve --> UpdateOK[Update list status to Approved<br/>record approver, timestamp, comment in columns]
    Response -- Reject/return --> UpdateNG[Update status to Returned<br/>notify requester of the reason]
    Response -- Timeout --> Remind[Reminder notification / escalation]
    UpdateOK --> NotifyOK[Notify requester of the result]
    UpdateNG --> Resubmit[Requester revises and resubmits]
    Resubmit -- Trigger condition fires<br/>only for resubmit --> Trigger

The key point is inserting a “record” step both before and after the approval action. I’ll explain why in Chapter 5.

4. How to Design the Request Intake

How usable an approval flow feels is decided less by the approval side and more by the intake for the requester’s input. There are three realistic options.

Here’s a rough guide for deciding.

• If you just want to digitize an occasional approval, you don’t even need to build a flow — Teams’ Approvals app is enough on its own. The Approvals app lets you send an approval request on the spot from a chat; it runs on top of the Power Automate platform, but building a flow isn’t required.⁹
• If you’re replacing a request form, the fastest route is to use Forms as the intake, receive the response in a flow, and route it to approval. There’s even a ready-made template that inserts Forms response content into an approval request.¹¹
• If you want to manage it as a request ledger, build around a SharePoint list. Even when Forms is your entry point, having the flow transcribe the response into the list right at the start means a status column (Pending / Approved / Returned) and a view can make “where is it stuck right now” visible to anyone. This, more than anything else, is where the answer to the paper-and-email approval problems from the opening lies.

For a small-scale start, a setup of “take input via Forms, record it in a SharePoint list, and write the approval result back into that same list” gets you both the ease of input and the ledger management, and is easy to work with.

5. Design Points That Matter in Practice

Where to Keep the Approval Record — Don’t Rely on Run History

This is the single most important design decision. A flow’s run history is visible for only 28 days by default.⁴ If the flow belongs to a solution, you can retain run history metadata in Dataverse, but the default retention there is also 28 days — it’s a mechanism where an administrator can adjust the retention period.¹²

In other words, an operational habit of looking up “who approved this, and when” via run history will fall apart within a month. The approval request/response records themselves are stored in Dataverse¹³, but checking a Dataverse table every time you need it for an audit or a routine inquiry isn’t realistic, and because approval history consumes an environment’s storage, it can end up getting deleted purely to free up space.¹⁴

In practice, always add a step immediately after the approval action that writes the result, approver, response timestamp, and comment back into columns of a SharePoint list. The “Start and wait for an approval” action returns the response, approver, and comment as outputs¹³, so you’re just recording those directly into the columns. This keeps the request and the approval record together on the same row of the same list, and the retention period can be as long as you want, depending on how you operate the list.

One thing to watch out for: for approval types with multiple approvers, such as “everyone must approve” or custom responses (everyone), the Responses output comes back as an array with one entry per person.³ Writing that into a single set of columns by overwriting them in sequence leaves only the last response behind, so for multiple approvers, either append one row per response to a history list, or format everyone’s responses into a single piece of text before writing it into a column.

Timeouts and Reminders — You Cannot Build “Approval With No Deadline”

A single cloud flow run lasts at most 30 days. That 30-day window includes pending steps like a waiting approval, and once 30 days have passed, the pending step times out.⁵ If the approver just leaves it sitting there, the flow quietly ends in failure. Start operating this without knowing that, and you get the single worst kind of incident for trust: “I submitted a request and nothing happened at all.”

The countermeasure has two parts.

1. Set an explicit timeout on the approval action. Specify a timeout in ISO 8601 format (e.g. P3D for 3 days) in the action’s settings, and add a “when it times out” branch under Configure run after.¹⁵ What matters here is that once the timeout fires, the original pending approval is already over. Even if the approver responds afterward, it no longer flows into this run’s later steps (writing back the result, and so on). In other words, the timeout branch isn’t a place to “keep waiting while nudging” — it’s a place to “cut the wait off and take the next action.” If you want to send a reminder, send the notification in the timeout branch and then issue a brand-new approval request. For something like “remind after 3 days, escalate to someone senior after 7,” the simplest and most reliable approach is to chain 2-3 timeout-equipped approval actions in series (the second stage reissues the request with a reminder, the third stage addresses someone more senior). You can also wrap “timeout -> remind -> reissue” in a Do Until loop, but Do Until has its own separate cap on the loop itself (60 iterations / 1 hour by default), and if you put a long-running action like a pending approval inside it, the second and later iterations won’t start unless you explicitly extend the loop’s timeout via Change limits.⁵¹⁶
2. Split the flow into two for any approval that might exceed 30 days. Microsoft officially documents a configuration where the “Create an approval (V2)” action sends only the approval request and ends the first flow there, with the follow-up processing of the response handled by a separate flow. Because the approval record lives in Dataverse, the response can still be processed even after the original flow’s run has ended. If you want to build flexible reminders without ever cutting off the wait, this two-flow configuration is also the more natural approach.¹⁷ Note that there’s design latitude in how the second flow gets triggered; if you have it pick up changes to the approval table directly via a Dataverse connector trigger, be aware that the Dataverse connector is classified as a premium connector (the Approvals connector’s own actions remain within the standard tier¹).¹⁸

For a small or midsize company’s approval process, a realistic approach is to first settle on an internal rule like “remind after 3 days, escalate to the manager after 7,” and implement that as either a reissue loop or a two-flow configuration.

Reassigning When Someone Is Unavailable

Cases where an approver is unavailable for an extended period are bound to happen. The person who received the approval request can reassign it to someone else from the approvals list in the Power Automate portal. On the requester’s side, recovering from this involves canceling the request and changing the flow’s approver before rerunning it.⁷ What’s worth noting is that in an automatically triggered flow like the one in this article, this becomes work for the flow’s owner, not the requester — because the approval request goes out from the account tied to the flow’s connection, and changing the approver requires edit permission on the flow. You need to decide, together with the co-owner question in the next chapter, who fixes the flow when the approver goes on leave.

That said, reassignment assumes “the person who received it can act on it,” so it doesn’t help with a sudden, unplanned absence. As a standing precaution, it’s safer to avoid fixing the approver as a single named individual, and instead specify multiple people, separated by semicolons, with a “first to respond” type, or direct the request at a group.⁷ Because directing it at a group means Teams notifications don’t fire⁸, choose the multiple-names approach if reliable notification matters more to you.

The Rejection-and-Resubmission Loop

The part of paper-based approval that was hardest to trace — “reject -> revise -> resubmit” — can be expressed cleanly with a design built around a status column. The basic shape is this.

• Define “Approve” and “Return” as custom responses¹
• On a return, set the list’s status column to “Returned,” record the approver’s comment in a column, and notify the requester
• The requester revises the list item and changes the status to “Resubmit” (or resubmits via Forms)
• The item update triggers the flow again, and it goes back to approval

There’s one thing to watch out for with this shape: the flow’s own write-back can retrigger the flow. If you leave the trigger as “When an item is created or modified,” then the moment the flow updates the status column to “Pending” or “Approved,” that update itself satisfies the trigger condition, causing duplicate approval requests or an infinite loop. A cloud flow can trigger itself, and Power Automate does warn you about the possibility of an infinite loop when you save.¹⁹ The fix isn’t to discard the case in a later conditional branch — it’s to write the rule into the trigger itself, using trigger conditions, so it only fires when the status column is “Resubmit” (or newly created). An update that doesn’t satisfy the trigger condition doesn’t even cause the flow to run, so it doesn’t consume a run count either.²⁰

Because the revision history is preserved in the list’s version history, this also resolves the problem of losing track of which version a piece of feedback was actually about. You could build a Do Until loop inside the flow to cycle through rejections within a single run, but since the 30-day run-length limit would then have to include the round-trip time of every rejection, it’s safer to design it so that each rejection ends the run, and resubmission starts a fresh one.

6. Operations and Governance — Don’t Let the Flow Become “the Creator’s Property”

Because an approval flow becomes woven into the core of a business process, letting it depend on a single person creates outsized risk. At minimum, take care of these two things on day one of going live.

• Set up co-owners. A flow’s owner can check the run history, edit or stop the flow, and even update the credentials on its connections. If it stays with a single creator, the flow becomes unfixable by anyone the moment that person leaves or transfers. Add your IT staff or a likely successor as co-owners. There’s also a feature that lets you make the SharePoint list itself a co-owner, aligning “anyone who can edit the list” with “anyone who can edit the flow”⁶, but if you do this on a list that every requester writes to, as in this article’s setup, you end up handing edit permission on the flow to every single requester. Don’t use it for an approval flow — restrict co-owners to the individual staff running operations, or an administrators’ group.
• Understand how connections are handled. A connection used by a flow (authentication to SharePoint or Outlook, for instance) is tied to the user who created it, and a shared connection can only be used inside that specific flow. Co-owners also can’t change the credentials on a connection another owner created.⁶ Incidents like “approval notification emails keep being sent from a departed employee’s account” or “the flow stops the moment that account is disabled” both stem from this. Deciding which account handles notifications and writes is something to settle before you build the flow, not after.

Also, note that even if you have other departments use the flow, you don’t need to share the flow itself with the people submitting requests. In this article’s design, the flow triggers automatically as long as people can enter data into the intake (Forms or the SharePoint list). Sharing should be limited to the people involved in editing and operating it, and co-owners should be kept to the bare minimum needed.²¹

Broader governance across Power Automate as a whole — licensing, environment separation, DLP policies — is covered in a separate article, “Automating Business Processes with Power Automate — Choosing Between Cloud Flows and Desktop Flows, and Designing Error Handling.” Since an approval flow is itself just one kind of cloud flow, the same thinking applies directly.

7. How Far Should You Go With Power Automate?

Power Automate’s approval mechanism is powerful, but it isn’t a tool for implementing a formal approval regulation exactly as written. Here’s a rough guide for where to draw the line.

As a rule of thumb, I look at it this way: once you draw the flow’s branching on paper and it no longer fits on an A4 sheet, you’ve started to go beyond what Power Automate is meant to cover. Rather than force the flow to keep growing, it’s often cheaper in the end to move the approval-route decision logic itself out (into a Dataverse table or a separate system), or to move to a dedicated system entirely.

Digitizing an approval flow is also often an entry point for rethinking paper and fax exchanges with parties outside the company. Once your internal approvals are digitized, fax-based orders and invoice exchange are the natural next candidates. These are covered in “Moving Fax Orders to the Web — Designing a Dual-Operation Period and the Practicalities of a Phased Migration” and “What Is EDI? Making Business-to-Business Ordering Easier — From Fax, Email, and Manual Entry to Data Integration.”

8. Summary

The real problem with paper and email approvals was never the effort itself — it was that “you can’t see the status, records are scattered, and rejections are hard to trace.” A Power Automate approval flow solves all three by bringing the request and the approval record together in a SharePoint list, and handling the approval action itself through Teams or Outlook. Being able to start this without additional system investment, in many cases, is also a real advantage for companies that have already adopted Microsoft 365.

At the same time, build one without knowing about the 28-day run-history limit and the 30-day run-length limit, and you end up with an approval flow where “the trail vanishes” and “requests silently fail.” Writing the result back, timeout branching, handling multiple approvers, and co-owners — get these four things into the design from the start, and an approval flow can run reliably for a long time. And the moment you find yourself wanting to implement the full complexity of a formal approval regulation exactly as written, that’s your cue to start looking at a dedicated system or a custom-built solution instead.

Related Articles

• Automating Business Processes with Power Automate — Choosing Between Cloud Flows and Desktop Flows, and Designing Error Handling
• Moving Fax Orders to the Web — Designing a Dual-Operation Period and the Practicalities of a Phased Migration
• What Is EDI? Making Business-to-Business Ordering Easier — From Fax, Email, and Manual Entry to Data Integration
• What Is a Digital Invoice? How Is It Different From “Emailing a PDF Invoice”?

Related Consulting Areas

Komura Software LLC handles everything from consulting on digitizing business processes with Microsoft 365 to building out approval and reporting requirements that go beyond what Power Automate can handle.

• Technical Consulting & Design Review
• Windows App Development
• Contact

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Frequently Asked Questions

Common questions about the topic of this article.

Can I build a Power Automate approval flow with only a Microsoft 365 license?

Yes. The Approvals connector is a standard connector, so any license that includes standard connectors (such as Office 365) is enough to build an approval flow. That said, approval data requires a Microsoft Dataverse database as its storage location; in the default environment, this is provisioned automatically the first time you create an approval flow. Combining it with a SharePoint list, Forms, Teams, or Outlook can also be done entirely with standard connectors.

What happens if an approver never responds?

A single cloud flow run lasts at most 30 days, and any pending step, including one waiting on an approval, times out once it passes 30 days — so there is no way to build 'approval with no deadline.' In practice, you set an explicit timeout on the approval action and add a 'when it times out' branch under Configure run after. Once a timeout fires, the original pending approval is over, and if the approver responds afterward, that response no longer flows into the run's later steps — so design the timeout branch to send a reminder and issue a brand-new approval request (escalating to someone more senior as the retry count grows), not to keep waiting while nudging. If you genuinely need to wait longer than 30 days, split the work into two flows: one that uses the Create an approval (V2) action, and a separate flow that processes the response.

Where do approval records end up, and can they be used for audits?

Approval requests and responses are stored as records in Microsoft Dataverse, and the flow's own run history is visible for only 28 days by default. Relying on run history for audits or later lookups is risky. In practice, I'd recommend writing the approval result, approver, timestamp, and comment back into columns of a SharePoint list at the end of the flow, so the request data and the approval record can both be viewed in one place.

What should I do when an approver is unavailable or has left the company?

The person who received the approval request can reassign it to someone else from their Power Automate approvals list. The requester side can't reassign directly, but can cancel the request, change the flow's approver, and rerun it. To guard against extended absences, design the approver as multiple people or a group rather than a single fixed individual, which makes things far less likely to get stuck. It's also important to set up co-owners for the flow itself from the start, in case the flow's owner leaves the company.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.