Power Automate Approval Workflows: Enterprise Governance in 2026

Approval workflows in Power Automate look simple until one waits a month, fails silently, or belongs to someone who left the company. This EPC Group guide covers what Microsoft documents about approval types, time limits, error handling and connector governance in 2026, then puts those rules together into one governed approval flow you can copy. Every limit below comes from Microsoft Learn, read on November 7, 2026; links are in the sources list at the end.

What changed in 2026

Three platform changes shape any approval design this year:

• The Power Automate mobile app is deprecated. Microsoft deprecated the Power Automate mobile app for iOS and Android effective August 31, 2026. Approvals continue to work through Teams, Outlook actionable messages and the Power Automate portal, and the Approvals app in Teams is the mobile path.
• Dataverse for Teams is deprecated. New Dataverse for Teams environments can't be created starting November 15, 2026, and environments that aren't upgraded are suspended on September 15, 2027. Microsoft's guidance is to build new apps, flows and agents in a Dataverse environment and then add them to Teams.
• Unmanaged developer environments are going away. New unmanaged developer environments can't be created starting November 15, 2026; suspension starts December 15, 2026 and deletion January 15, 2027. Managed developer environments are not affected.

Approval types and where approvers respond

Microsoft's approvals page says there are four approval types, but its table lists five:

Parallel approvals are built with parallel branches; a step added after the branches runs only when every branch has finished.

Approvers can respond from an Outlook email, a Microsoft Teams adaptive card or the Power Automate action center. Actionable approval emails are not supported for guest users, who use the Power Automate portal instead. If an approver responds by email or in the action center, the Teams card does not update on its own; Microsoft's workaround is to turn off the default email notification when Teams is the primary surface.

Approvals need a Dataverse database. In the default environment it already exists; in any other environment the first approval run creates it, and the user who runs that first flow must be an environment administrator. Because the approvals connector is a standard connector, any license that grants Power Automate use is enough to send approvals.

One governance detail is easy to miss: approvals created directly in the Teams Approvals app, without a flow, are always stored in the organization's default environment, which does not support backups. The Approvals app also has not been released to GCC High or DoD. Those approvals are audited in Microsoft Purview (created, approved, rejected, canceled, reassigned, file attached), but they sit outside whatever environment strategy you built for flows.

The 28-day ceiling and long-running approvals

Microsoft's limits page gives a cloud flow a 30-day run duration, including flows waiting on approvals, after which pending steps time out. Its approvals known-issues page is stricter: an approval flow can wait for 28 days, and after that the flow fails while the approval stays in the action center, where the requester or an environment admin must delete it by hand. Design to 28 days.

For anything that might wait longer, Microsoft recommends storing approvals in Dataverse and using two flows: one sends the approval with "Create an approval", and a second runs the business logic when the response arrives. That pattern removes the run-duration limit from the approval itself.

Other limits that matter for approval flows:

• Run history is kept for 30 days from the start of each run.
• A flow whose trigger or actions fail continuously for 14 days is turned off, and a flow that isn't triggered for 90 days might be turned off (flows owned by premium or Process-licensed users are exempt).
• Approval create requests are throttled at 50 per flow per 60 seconds.
• Use a condition or switch on the outcome instead of a do-until loop, and handle Approved, Rejected and Canceled, so the flow can't loop forever.
• Keep "Create an approval" and "Wait for an approval" next to each other; if an approver responds before the flow reaches the wait action, the flow can become stuck.

Error handling Microsoft documents

Power Automate's guidance is to use Run after settings to say what happens when an action fails, times out, is skipped or succeeds, and to group actions in scopes: a "Try" scope for the main work and a "Catch" scope configured to run only if "Try" fails. Inside "Catch", a Filter array action over the result() of the "Try" scope pulls out the failing action and its error. A Terminate action with a status of Failed and a message ends the run cleanly, and Application Insights can alert on flow errors. Microsoft prefers exponential retry policies; for flows on the Medium and High performance profiles the default retries up to 12 times at exponentially increasing intervals, and a custom policy allows up to 90 attempts and a one-day maximum delay. Microsoft also cautions that heavy custom logging can become an anti-pattern because it multiplies actions.

A worked example: a governed purchase approval

Putting those rules together, a purchase approval that EPC Group would accept into production looks like this:

1. Build it in a solution in a managed development environment, so the flow is portable and deploys as a managed solution to test and production.
2. Trigger on the request (a SharePoint list item or a Power Apps submission), and write a request record to Dataverse with a status column.
3. Try scope: "Start and wait for an approval" (or "Create an approval" plus "Wait for an approval", side by side) with the type that matches policy, for example First to respond for low amounts and Sequential for amounts that need two levels.
4. Switch on the outcome with explicit branches for Approved, Rejected and Canceled; each branch updates the Dataverse record.
5. Catch scope, run after "has failed" and "has timed out": filter the result() of the Try scope, write the error to the record, notify the process owner in Teams, then Terminate with status Failed.
6. Long waits: if policy allows approvals to wait more than 28 days, split into the two-flow Dataverse pattern instead of one long wait.
7. Ownership: run it under a service principal, which Microsoft recommends for mission-critical flows because it insulates ownership from any one person's lifecycle (a premium flow owned by a service principal needs one of the licensing options Microsoft lists, such as a Process or per-flow license).
8. Monitoring: Power Platform inventory shows every flow tenant-wide and helps find flows owned by departing users; its owner column for cloud flows shows the creator and does not update when ownership changes, so the ownership record lives with the solution.

Connector governance: data policies, environments and ownership

Data policies (Microsoft's current name for DLP in Power Platform) sort connectors into Business, Non-Business and Blocked groups; connectors in different groups can't share data, and a new policy places every connector in Non-Business by default. Core connectors such as Dataverse, Approvals, Notifications, SharePoint, Microsoft Teams and Microsoft 365 Outlook can't be blocked by a standard data policy, although the newer advanced connector policies use an allowlist model that can restrict them. When several policies apply, Blocked always wins, and Microsoft recommends applying as few policies as possible to any one environment. Existing flows that violate a new policy are suspended, usually within an hour and in extreme cases up to 24 hours.

For the default environment, which every employee can reach, Microsoft recommends renaming it to something like Personal Productivity Environment and setting the Blocked group as the default so new connectors stay unusable until reviewed. Managed Environments add sharing limits, usage insights, pipelines and the solution checker, and are included with standalone Power Apps, Power Automate, Copilot Studio, Power Pages and Dynamics 365 licenses.

For Power Automate workflow automation consulting, ownership is part of governance. Non-solution-aware cloud flows can't change owner in place because the owner is part of the flow identity, Microsoft advises co-owners only when collaborative editing is needed, and a flow with no active owner should be reassigned. The CoE Starter Kit is no longer actively maintained; its core capabilities (Inventory, Usage, Monitor and Actions) are now in the Power Platform admin center.

Custom line-of-business apps on Power Apps integrated with Teams

Approval flows usually sit behind an app. With Dataverse for Teams deprecated, custom line-of-business apps on Power Apps integrated with Teams are built in a Dataverse environment and then added to Teams as a tab or personal app with the Power Apps tab; the app must be shared before it is added. Existing Dataverse for Teams environments need an upgrade before the September 15, 2027 suspension, and after the upgrade their apps and flows need Power Apps or Power Automate licenses.

Copilot in Power Automate

Copilot can build a cloud flow from a natural-language description over several turns, in the new designer only, and it supports a subset of connectors. Microsoft's pages don't label it generally available or preview, and they disagree on whether Copilot can help fix flow errors, so EPC Group treats Copilot-built flows as drafts that still go through the same solution, testing and data-policy review as any other flow.

How EPC Group approaches approval workflows in Power Automate

EPC Group designs approval workflows in Power Automate from the policy down: approval type per threshold, the 28-day rule, the Try/Catch and outcome handling above, solution-based deployment through Managed Environments, data policy placement and service-principal ownership. The same pattern carries into our Power Platform consulting and Power Platform Center of Excellence work; see also our enterprise workflows guide and the Teams Approvals app overview.

Frequently asked questions

How long can a Power Automate approval wait?

Design to 28 days. Microsoft's known-issues page says an approval flow fails after waiting 28 days, while the approval itself stays in the action center; the limits page gives cloud flows a 30-day run duration. For longer waits, Microsoft recommends storing approvals in Dataverse and splitting the work into two flows.

Where can approvers respond now that the mobile app is deprecated?

In Outlook actionable messages, in Teams (adaptive cards and the Approvals app) and in the Power Automate action center. The Power Automate mobile app for iOS and Android was deprecated on August 31, 2026, and guest users can't use actionable approval emails.

Can a data policy block the Approvals connector?

Not a standard data policy: Approvals, Dataverse, Notifications, SharePoint, Teams and Microsoft 365 Outlook are among the connectors a standard data policy can't block. Microsoft's newer advanced connector policies use an allowlist model that can restrict them.

Who should own a production approval flow?

A service principal, for mission-critical flows, so the flow doesn't depend on one employee's account. Microsoft notes that a service principal can't be a co-owner and that premium flows owned by one need a Process or per-flow license.

Why does the Teams approval card not update when someone approves by email?

Microsoft documents that when an approver responds by email or in the Power Automate action center, the Teams adaptive card does not update on its own. The workaround Microsoft gives is to turn off the default email notification when Teams is the primary place approvers respond.

Sources

Microsoft Learn, accessed November 7, 2026: Get started with approvals, Manage approvals, Known issues with approvals, Modern approvals, Parallel approvals, Approvals in Teams, Approvals app admin, Approvals connector, Limits and configuration, Error handling guidance, Data policies, Connector classification, Combined effect of multiple data policies, Secure the default environment, Managed Environments, Share a cloud flow, Service principal owned flows, Power Platform inventory, CoE Starter Kit transition, Important changes coming, Power Apps and Teams, Create a flow with Copilot.