30-Day Timeout on Approvals in Power Automate: The Relay Pattern as a Solution

Why Power Automate approvals time out after 30 days and how the relay pattern of two flows reliably handles long-running approvals.

An approval flow in Power Automate waits patiently as long as the approver doesn't respond, but this patience isn't unlimited. If an approval runs through an extended absence, parental leave, or an investment decision that isn't due until next quarter, the underlying flow run can simply terminate before any response has even come in. For teams that rely on a single continuously running flow, this is an unpleasant blind spot: the request still looks normal in the approver's inbox, but in the background the process is already dead.

This article explains why Power Automate ends approvals after roughly 30 days, what happens somewhat earlier in practice, and how the so-called relay pattern with two separate flows can be used to cleanly handle approvals with an indefinite duration. As of: July 2026.

Why Power Automate cancels approvals after 30 days

The cause doesn't lie in the approval feature itself, but in a general runtime limit for cloud flows. According to the limits for automated, scheduled, and instant flows a maximum runtime of 30 days applies to every individual flow run, calculated from the start time of the execution. The documentation states this clearly: the runtime also covers runs with pending steps such as approvals, and after 30 days a timeout occurs for pending steps.

This mainly affects the Start and wait for an approval action, because it blocks the flow run until a response arrives. This very blocking becomes its downfall as soon as the wait time reaches the 30-day limit. At that point, the flow technically has no way to continue running, regardless of whether the approver has overlooked the request or simply hasn't gotten around to it yet.

What actually happens after just 28 days in practice

In the overview of known issues with approvals Microsoft points out a particularity that is more relevant in practice than the documented 30 days: an approval process can reportedly wait 28 days, and if the wait time exceeds these 28 days, the flow fails. It's important to note that this failure only affects the flow run itself. The approval remains visible in the approvals center even though no flow is waiting for it anymore.

This leads to orphaned entries that an approver can theoretically still respond to, without that response ever arriving anywhere. The requester or an environment administrator must manually delete such orphaned approvals from the action center. Anyone who regularly sends approvals with an unclear duration should build this cleanup step firmly into their process maintenance instead of relying on old entries disappearing by themselves.

The relay pattern: two flows instead of one long run

Microsoft's recommended solution for approvals with a potentially long runtime is splitting the process into two independent flows. According to the guide Create and test an approval workflow with Power Automate the rule is: if a flow runs for longer than 30 days, the approvals should be stored in Microsoft Dataverse. This makes it possible to create flows that react to responses even after the original flow run has long since expired.

Specifically, you use the action Create an approval (v2) instead of the blocking Start and wait for an approval action:

  • Flow A only sends: It creates the approval request via Create an approval (v2), writes the approval ID together with the process context to a Dataverse table or another source system, and then ends immediately. No 30-day clock is ticking here, because the flow doesn't wait.
  • Flow B handles the logic: A second, independent flow reacts to the response, for example via a Dataverse trigger on status changes or via the action Wait for an approval, linked to the previously stored approval ID. It only executes the actual business logic once a decision is actually made, whether that's after three days or three months.

This handover from a sending flow to a waiting flow is the actual relay pattern: instead of a single runner who has to endure the entire distance alone, a second flow takes the baton and isn't bound by any runtime limit of the first.

A pitfall when splitting create and wait

The known issues mention an effect that many overlook when first building the relay pattern: if the approver responds very quickly, before the flow has even reached the wait action, the flow can get stuck in the waiting phase. Microsoft therefore recommends calling the Create and Wait actions as close together as possible within the flow, or alternatively checking the approval status in Dataverse before the wait action is even started. For a clean relay pattern, it's worth taking a close look at exactly this sequence before putting the flow into production.

Special case: approvals kit with automatic restart after timeout

Anyone using the prebuilt approvals kit, i.e. the business approval management app, instead of their own flows, already gets part of this safeguard included. According to the approval status reference there is a status called Pending (Timeout): it means that the approver did not respond within the first 30 days and the Power Automate cloud flow run managing this request is automatically restarted. After the restart, the status switches back to Pending, and the request remains valid.

This is a convenient automation, but it only applies within the approvals kit with its Dataverse connection, and not automatically for every self-built flow. Anyone running their own approval flow without this kit has to rebuild the restart mechanism themselves using the two-flow pattern described above.

Practical tips for robust long-running approvals

  • Plan the relay pattern in from the start as soon as an approval could realistically stay open for longer than three to four weeks, rather than only reacting once the first flow has already failed.
  • Store the status and approval ID outside the flow, for example in Dataverse or a SharePoint list, so that a second flow can pick things up at any time.
  • Build in a reminder that goes to the approver again after about 20 days, so the decision falls within a practically usable time window.
  • Clean up orphaned approvals in the action center regularly, so that old requests aren't accidentally answered without any flow still reacting to them.

Anyone who doesn't want to build this pattern alone, or needs to safeguard several approval processes at once, can get support from a specialized provider like NordFlux. You retain control over your process while the technical safeguard against the 30-day limit runs cleanly in the background.

Frequently asked questions

Exactly when does a Power Automate approval time out?

Officially documented is a maximum runtime of 30 days per flow run, but in practice, according to Microsoft, the flow can already fail after 28 days if the wait time exceeds this value. For planning purposes, you should play it safe and calculate with the lower value.

What happens to the approval that's left behind in the action center?

It remains visible and looks normal at first glance, even though no flow is waiting for a response anymore. A response from the approver then goes nowhere, which is why such orphaned entries should be manually removed from the approvals center.

Is the relay pattern sufficient for unlimited wait times?

Yes, because the waiting second flow only ever runs for as long as a single wait action allows, and it can be triggered again as needed, as long as the approval information remains stored centrally in Dataverse or another source system. This doesn't lift the 30-day limit of a single run, but makes it irrelevant for the overall process.

Does the automatic restart after timeout also apply to self-built flows?

No, the automatic restart with the status Pending (Timeout) is a feature of the prebuilt approvals kit with its own Dataverse structure. For an individually built approval flow, you have to replicate this mechanism yourself using the two-flow pattern.

How do I choose between the two-flow pattern and the ready-made approvals kit?

For individual, specific approval processes with their own logic, the self-built two-flow pattern is usually the more suitable and leaner solution. If, on the other hand, several similar approval processes need to be managed consistently across the company, it's worth looking at the approvals kit, because it already comes with timeout handling and status logic.

About NordFlux

NordFlux UG (haftungsbeschränkt)

NordFlux builds digital employees for organisations: automations and AI agents that take over repetitive work. You stay in control.

More about us
Free initial analysis

Concrete questions about automation or AI?

In a free initial analysis we discuss your case directly. No strings attached.