How Power Automate Approval Flows Save Mid-Market Finance Teams Time

Where does a finance team's approval time actually go?

Ask a mid-market controller where the finance team's time disappears and the answer is rarely the accounting itself. It is the chasing. An invoice over a threshold needs the department head's sign-off, so someone forwards a PDF and waits. The approver is travelling, so it sits for three days. A purchase order needs two approvers because of its value, so it bounces between inboxes until someone forgets who has it. Month-end close slips because half a dozen approvals are still "out there" with no system of record showing where. That chasing is exactly the work an approval flow takes off the team.

This is the unglamorous reality of finance operations in the 50-to-500-employee range: enough volume and enough policy to need controls, but rarely a dedicated workflow platform to enforce them. The controls live in people's heads and in email. Power Automate's approvals capability exists precisely to move that logic out of inboxes and into a flow that routes, escalates, and records every step - and because it sits inside the Microsoft 365 and Dynamics 365 stack most mid-market companies already pay for, it does so without a new system to buy or learn.

What does a Power Automate approval flow actually do?

A Power Automate approval flow is a sequence triggered by an event - an invoice arrives in a SharePoint library, a new record is created in Dataverse, a form is submitted, a row lands in a Dynamics 365 table - that then sends a structured approval request to one or more people and waits for their response. The approver acts from Outlook, Teams, or the Power Automate mobile app with an Approve/Reject button and a comments box; they never have to open a separate portal. The flow captures the decision, the comments, and the timestamp, then continues: posting the invoice, notifying the requester, updating the record's status, or moving to the next approver.

The mechanics that matter for finance are the ones that encode policy:

• Conditional routing. A flow can branch on the amount. Under €5,000, one approver; over it, the department head and then finance. The threshold lives in the flow (or better, in a Dataverse configuration table), not in someone's memory.
• Sequential and parallel approvals. Sequential when authority is hierarchical - manager, then director. Parallel when two stakeholders must both sign off but in no particular order, which collapses a multi-day relay into a single round.
• Escalation and reminders. If an approver does not respond within a set window, the flow can send reminders and then reassign or escalate to a delegate. The request stops being something a human has to remember to chase.
• A complete audit trail. Every approval action is logged with who, what, and when - exactly what an auditor asks for and exactly what email threads fail to provide cleanly.

Why do approval flows fit the Dynamics 365 and Dataverse world?

The leverage compounds when the data already lives in Dataverse. If your finance or operations records sit in Dynamics 365 - vendor records, purchase requests, project budgets - a flow can trigger directly off a row's creation or a status change, read related data to decide routing, and write the outcome straight back to the same record. The approval is not a parallel process bolted onto your system of record; it is part of it.

That is the difference between a flow that automates a task and one that automates a process. A common mid-market mistake is to build approvals as a standalone gadget - a SharePoint list here, a form there - disconnected from where the financial data actually lives. Built on Dataverse, the flow inherits the security model, the audit logging, and the relationships already defined, so an approved purchase order updates the vendor's record, triggers the next step, and stays governed by the same role-based permissions as everything else. This is the integration work that separates a demo from a deployment, and it is the heart of what our services focus on.

For finance and banking organizations specifically, where segregation of duties and documented authorization are not optional, this matters even more - we cover the regulatory and control angle in more depth on our financial services page.

Where do teams get approval flows wrong?

The technology is the easy part. The failures are predictable:

• Automating a broken process. If your approval matrix is unclear or inconsistent on paper, encoding it in a flow just makes the confusion run faster. Map the real authority thresholds and exception paths first.
• No delegate or escalation path. A flow that routes to one named person and stops when they are on holiday is worse than email, because at least email gets forwarded. Build in delegates and time-based escalation from day one.
• Over-notifying. Approvers who get pinged for every trivial request learn to ignore the pings. Use conditions so only requests that genuinely need a human reach one; auto-approve the routine low-value items against policy.
• Ignoring error handling. Flows fail - a connector times out, a record is locked. Without configured run-after steps and failure notifications, a silently failed approval is a payment that never happens and nobody noticed.
• Holding approval state inside a running flow. A flow run that waits on a person for days is a common cause of approvals that time out, cannot be reassigned or vanish when the flow is changed. The durable alternative is set out below.

Why do long-running approvals get stuck or time out in Power Automate?

The architectural mistake behind most stuck approvals is holding approval state inside a single running flow. A cloud flow run lasts at most 30 days, a resubmitted or cancelled run loses its place, and a request waiting on one person cannot be moved when that person is on leave. The durable pattern keeps state in a Dataverse or SharePoint table instead. A trigger flow writes each stage to the table, sends the approval and exits. A separate scheduled watchdog flow escalates, reassigns to registered delegates and reports what is overdue. Routing by amount and department reads from configuration, and every decision is written back as an audit row. Approvals, Outlook, Teams and SharePoint connectors are standard; Dataverse is premium.

The symptoms are familiar to anyone who has inherited a purchase order flow: a request that shows as pending for weeks, a run that failed quietly on day 30, a payment held because the only named approver is on holiday, and nobody able to say how many requests are in that state. None of these is a bug in Power Automate. They come from using a single flow run as the database for a process that lives longer, and changes more, than any one run should.

What does the durable approval pattern look like?

Separate the record of the approval from the flows that act on it. Four parts do the work:

• A state table. One row per request and one row per stage, holding the request, the amount, the department, the current stage, the assigned approver, the due date, the status and the outcome. This is the system of record for where every approval is, and it survives any flow being edited, turned off or failing.
• A trigger flow per stage. When a stage row is created, the flow resolves the approver from the routing rules, sends the approval, waits for a response only up to that stage's escalation window, writes the outcome and the responder back to the row, and exits. The wait is set with the action's timeout setting, so no run gets anywhere near the 30-day limit. A timed-out stage is recorded as timed out, not left hanging.
• A watchdog flow. A scheduled flow reads the state table, not the flow run history. It sends reminders on stages nearing their due date, reassigns or escalates the ones past it according to the rules, and sends a daily list of anything overdue to the process owner.
• Configuration tables. Approval thresholds by amount, approvers by department and cost centre, escalation windows and delegations live in tables that finance can maintain, not in conditions inside a flow that only a developer can change.

Because the state is in a table, a report of every approval in progress is a view, not an investigation, and fixing or redeploying a flow does not lose a single request.

How should multi-stage approvals be sequenced?

As a chain of short stages, not one long run. When a stage row is completed as approved, a flow reads the routing rules for that request and creates the next stage row, which triggers the next approval. A rejection closes the request and notifies the requester. The request row always shows which stage it is at.

• Sequential stages suit hierarchical authority: budget holder, then department head, then finance.
• Parallel stages suit sign-offs that must all happen but in no order: create several stage rows at once and advance only when all are approved.
• Conditional stages come from the rules, not the flow: a purchase order above the threshold for its department gets an extra stage, one below it does not.

Keep the routing decision at the moment the stage is created and record which rule applied on the row, so an auditor can see why a request went to the people it went to.

How do you handle an approver who is on leave without breaking controls?

Register delegation in advance rather than improvising it on the day. A delegation table holds the approver, the delegate, the start and end dates, and the scope, for example the departments or amount limit the delegate may approve. When a stage is created, the trigger flow checks the table and assigns the delegate directly if a delegation is active, and records on the stage row that it did.

For the case nobody planned for, an approver who is suddenly absent with payments waiting, provide one emergency exception path. A named role, such as the financial controller, can reassign a stuck stage from a simple app or view, must give a reason, and cannot reassign to themselves where that would breach segregation of duties. The reassignment cancels the waiting stage flow run, creates a new approval for the new assignee and marks the original request as superseded so a late response to it is ignored, and it is written to the state table with who, when and why, and the watchdog reports all emergency reassignments to the process owner. The approver can also reassign a request from the approval itself, but that only helps when the approver is there to do it.

Can approvers stay in Outlook while the decision is recorded in Dynamics 365 or Dataverse?

Yes. The standard Approvals action sends an actionable message: the approver clicks Approve or Reject and adds a comment in Outlook or Teams, without opening Dynamics 365 or a portal. The flow waiting on that response writes the decision, the responder, the comment and the time to the stage row, so the decision lands in your table even though the approver never left their inbox.

That is more dependable than asking people to reply to an email with the word approved and parsing the reply, which breaks on signatures, forwarded threads and replies from a different address. Classic Dynamics 365 workflows are also a poor fit for this, since they cannot hold an interactive approval conversation; Power Automate is where Microsoft is taking this kind of automation.

Which parts of the pattern need premium connectors?

• Standard: the Approvals connector, Office 365 Outlook, Microsoft Teams, SharePoint and the recurrence trigger for the watchdog. A state table built as a SharePoint list can run the whole pattern on standard connectors.
• Premium: the Dataverse connector used by a standalone flow, and connectors such as HTTP. Flows that run in the context of a Dynamics 365 app and use its data are covered by Dynamics 365 licences in many cases, but the rules depend on the licence and the use, so check your licence before you design around it.

A SharePoint list is a reasonable home for moderate volume and simple permissions. Dataverse is the better home once you need row-level security, field auditing, relationships to vendors, purchase orders and budgets, or reporting across many processes. Where the approval process has to live outside the Microsoft stack altogether, the same state table and watchdog design applies to a custom-built CRM or workflow application. Designing and rescuing approval flows like these is part of our Power Automate consulting.

What should you do when you already have fifteen or more approval flows?

Start with an inventory, not a rebuild. Teams that reach fifteen or more approval flows usually got there one department at a time: an invoice flow, a purchase order flow, three expense variants, a contract sign-off, each built by whoever needed it, several owned by people who have since left, and some quietly carrying compliance weight. Before consolidating anything, list every flow and answer four questions for each, then consolidate into one parameterised parent process with routing held in a table, child flows only for genuinely different cases, and connections that belong to the company rather than to a person.

• The flow: name, environment, trigger, what it approves, whether it sits in a solution, and its last successful run.
• The owner: the primary owner and co-owners, and whether each one is still employed.
• The connection: which account every connection runs under, personal or service account, and whether it is healthy.
• The regulated dependency: whether a documented control, such as payment authorisation, segregation of duties or a record a regulator or auditor relies on, depends on the flow.

Add the approval rules each flow encodes, thresholds, approvers and escalation, because those rules are what the consolidated process has to reproduce. Flows with a departed owner, a personal connection and a regulated dependency go to the top of the list. The admin tooling and the recovery steps for a flow still running on a leaver's connections are set out on our Power Automate consulting page, and when the flows authorise payments or move money, containment and governance come before consolidation, as covered in our guide to Power Automate flows running financial transactions.

How do you consolidate approval flows into one governed process?

Most of the fifteen flows turn out to be the same process with different numbers in it. The consolidation keeps one parent process and moves the differences into data.

• One parameterised parent process. A single set of flows, built on the durable pattern above with a state table, stage flows and a watchdog, handles every approval type. Each request carries its process type, such as invoice, purchase order, expense or contract, and the parent reads everything else from configuration.
• Routing configuration in a table. A Dataverse routing table keyed by process type, department or cost centre and amount band defines the stages, their order, whether they run in sequence or in parallel, the approver role for each stage and the escalation window. Approvers are resolved from roles to people through a second table, so a change of budget holder is a row edit, not a flow change.
• Child flows only for genuinely different cases. When a process type needs steps the parent cannot express, such as posting to a finance system after approval or collecting extra evidence before a stage, put that work in a child flow the parent calls. A different threshold or a different approver is configuration, not a reason for a child flow. Child flows need to be in a solution, and the connections they use have to be embedded in the child flow rather than supplied by the person running it, so check current Microsoft documentation for the requirements before designing around them.
• Connection references and service accounts instead of personal accounts. The parent and child flows live in a solution, use connection references and run under a dedicated service account, or a service principal where the connector supports it, so nothing breaks when an employee leaves. Promote the solution from development through test to production as a managed solution, and give ownership to a team or service account with named human co-owners.

Keep one audit shape across every process type: the same state table, the same outcome columns, and the routing rule recorded on each stage. An auditor then reviews one control, not fifteen.

Which failure modes does consolidation have to remove?

Two failure modes cause most of the incidents in an unconsolidated estate, and the design should make each one structurally impossible rather than unlikely.

• The single approver. A flow that routes to one named person stalls when that person is away, leaves or changes role, and often nobody knows until a supplier chases payment. In the consolidated process every stage resolves to a role with at least two eligible people, delegations are registered in advance, and the watchdog escalates anything past its window. A routing row that resolves to fewer than two active people should be reported as a configuration error before it is ever used.
• The orphaned owner. A flow owned by, or running on the connections of, someone who has left fails the next time their password changes, their account is disabled or their licence is reclaimed, and it fails for every request at once. Company-owned connections, team or service account ownership, named co-owners and platform notifications routed to a shared mailbox remove it. The inventory should be rerun periodically so a new personally owned approval flow is caught while it is still one flow.

In what order do you migrate approval flows without freezing the business?

Never switch everything on one day, and never move a process in the week of month-end close. Migrate by process type, so each one moves on its own date and the old flow carries on until the new one is proven.

1. Contain the current estate. Add co-owners to every flow, export a backup of each definition, re-point the most fragile personal connections, and add a kill switch to critical flows, so nothing fails while the new process is being built.
2. Build and test the parent process with its routing and role tables in a development environment, then promote it to test with realistic routing data.
3. Move one low-risk, high-volume process type first, such as expense approvals. New requests start in the new process from an agreed date, while requests already in flight finish on the old flow.
4. Run both for a full period and compare outcomes: every request routed to the right people, escalations fired, audit rows complete.
5. Move the remaining process types one at a time, saving the regulated ones for when the pattern is proven, and agree each cut-over date and the evidence of testing with the control owner.
6. Move each process type between close periods, and communicate the date to approvers so an approval request from a new sender does not look like phishing.

How do you retire the old approval flows safely?

Retire in stages, because deleting a flow deletes its evidence with it.

• Stop new requests first. Once the process type has cut over, change or turn off the old trigger so no new runs start, and leave in-flight runs to complete or move them across deliberately.
• Keep the evidence. Power Automate keeps run history only for a limited period, so export the approval outcomes and anything auditors may need into the state table or an archive before the history expires, and check current Microsoft documentation for the retention period.
• Turn off, then delete. Keep the retired flow turned off for an agreed period, typically at least one full reporting cycle, before deleting it and removing its connections.
• Update the inventory. Mark the flow retired, record the date and the process type that replaced it, and remove any personal connections that only it used.

When the last old flow is retired, the inventory becomes the register for the governed process: one parent process, its child flows, their connection references and the routing tables finance maintains.

What is the concrete payoff for a mid-market finance team?

The win is not abstract "efficiency." It is a finance team that stops spending Friday afternoon reconstructing which invoices are still waiting and on whose desk. Approval cycle times drop from days to hours because escalation does the chasing. Month-end close gets more predictable because the status of every sign-off is visible in real time rather than scattered across inboxes. And when the auditor arrives, the trail is already there - exportable, timestamped, and complete.

For a mid-market finance team, that is several hours a week of low-value chasing converted back into actual finance work, achieved with tooling already inside the Microsoft licensing they hold. If you want to see what this looks like applied to your own approval matrix, get in touch and we will walk through a specific process with you.