Power Automate’s 30-Day Run Limit: Safe Patterns for Long Approvals

A single automated, scheduled or instant Power Automate cloud-flow run can last for a maximum of 30 days. Microsoft calculates that duration from the run’s start time, and it includes pending actions such as approvals.

If a business process can take longer, the fix is not a longer Delay, a child flow or a magic timeout value. The process needs durable state outside one waiting run.

Fact-checked against Microsoft Learn on 24 August 2026.

The short answer

A single cloud-flow run has a documented 30-day maximum duration.
A pending approval inside that run times out when the run reaches the limit.
Run-history retention is also documented as 30 days, but it is a separate limit.
For an approval that may exceed 30 days, Microsoft documents storing approvals in Dataverse and using two flows around Create an approval (v2).
For a wider long-running business process, store the process state in SharePoint or Dataverse and let short-lived flows advance, remind, reconcile and complete it.

What the 30-day limit actually means

Microsoft’s current limits page says:

Run duration: 30 days. Run duration is calculated using a run’s start time and includes flows with pending steps like approvals. After 30 days, any pending steps time out.

That clock does not restart because the flow entered a different branch, ran a child flow or reached a later approval stage.

The limit applies to one run:not necessarily to the whole business process. A process can last months if it is represented by durable records and a sequence of separate, bounded runs.

Do not confuse four different limits

Limit or rule	What it affects
Run duration	One flow run, including waits and pending approvals
Run retention	How long run history is retained in storage
Inactivity suspension	Flows that are not triggered for a documented period may be turned off, with licensing exceptions
Request and throttling limits	How much work a flow can perform over time

A flow that times out after 30 days does not prove it was suspended for inactivity. A consistently throttled flow is not fixed by an approval redesign alone. Diagnose the actual condition in run history and the flow’s status.

Choose the pattern from the business deadline

Process shape	Starting pattern
Approval normally completes in hours or days and must never approach 30 days	`Start and wait for an approval`, with an explicit timeout and escalation path
Approval can legitimately remain open beyond 30 days	Microsoft’s Dataverse-backed, two-flow long-running approval pattern
Multi-stage process may last months and approval is only one part	Durable process record plus short-lived stage/reminder/reconciliation flows
No human approval is required; work simply resumes later	Store next-action time and use a scheduled/event-driven flow rather than one long Delay

Pattern 1: keep ordinary approvals comfortably below 30 days

For a normal approval, Start and wait for an approval can be the simplest design. But do not allow the documented platform maximum to become the business deadline.

Define:

expected response time;
reminder times;
escalation owner;
a final timeout;
cancellation behaviour; and
what happens to the business item after timeout.

For example, a purchase approval might require:

reminder after two business days;
escalation after four;
expiry after seven; and
a visible Expired business status that a process owner can restart.

The action’s timeout branch should update the business record and notify an owner. A run that quietly times out leaves people unsure whether the request was rejected, lost or still pending.

Use Power Automate’s Configure run after behaviour to handle timeout and failure deliberately. Test the timeout with a short non-production value; do not wait 30 days to discover the error path is empty.

Pattern 2: use Microsoft’s long-running approval design

Microsoft documents a specific approach when an approval might run for more than 30 days:

Store approvals in Microsoft Dataverse.
Use one flow to create and send the approval with Create an approval (v2).
Use another flow to run the business logic when a response is recorded.

The important change is architectural. The first flow does not sit on Start and wait for the life of the request. The approval record survives independently, and a later flow handles the response.

Follow the current Microsoft Learn long-running-approval guidance and the current Approvals/Dataverse schema available in your environment. Do not paste numeric status codes from an old blog post. Internal values and supported tables can change, and the meaning of a number is invisible to the next maintainer.

What to record alongside the approval

Keep a business-owned record containing at least:

a process or request ID;
the approval ID returned by the action;
current stage;
assigned approver or group;
requested date;
due and escalation dates;
business status;
outcome and response date; and
last error or reconciliation result.

The approval service record and the business record have different jobs. The first powers the approval experience. The second lets the organisation report, support and recover the process.

Pattern 3: model the process as durable state

Some processes contain multiple approvals, document collection, external waits and scheduled reviews. Treating all of that as one flow run creates a fragile timeline.

Instead, create a durable state record in SharePoint or Dataverse. Each flow run does one bounded job and updates the record.

Example state model

Field	Purpose
`ProcessId`	Stable correlation ID for the whole process
`BusinessKey`	Link to the purchase, case, employee or document
`Stage`	Current business stage, using names your team owns
`Status`	`Pending`, `Completed`, `Expired`, `Cancelled` or another documented value
`AssignedTo`	Current owner or approver
`RequestedAt`	When the current stage began
`DueAt`	Business deadline
`NextActionAt`	When a reminder or reconciliation is due
`CompletedAt`	When this stage finished
`Outcome`	Approved, rejected or another business result
`LastProcessedAt`	Supports monitoring and stale-item detection
`ErrorSummary`	Safe operational error detail
`Version`	Helps detect repeated or out-of-order processing

Use your own documented status values. Do not couple the process to undocumented numeric codes from another system.

Split the automation by responsibility

A maintainable design might have:

Request flow : validates input, creates ProcessId, writes state and starts the current stage.
Response flow : receives a supported approval/event response, checks the current stage and advances once.
Reminder flow : runs on a schedule and sends reminders for records whose NextActionAt is due.
Reconciliation flow : finds stuck or inconsistent records and alerts an owner.
Cancellation flow : closes the business record and, where supported, cancels the approval.

These names describe roles, not mandatory products. Use the fewest flows that make ownership and failure paths clear.

Make every transition idempotent

Retries and duplicate triggers happen. A response-processing flow must be safe to run more than once.

Before performing a side effect, check:

is this still the expected Stage?
is the record already Completed or Cancelled?
has this response or event ID already been processed?
does the version match the one the run read?
has the notification, document or downstream record already been created?

Use a deterministic key such as ProcessId-Stage-Action for side-effect records where the data source supports uniqueness.

If a run repeats, it should recognise completed work and exit cleanly rather than sending a second approval or updating the next stage twice.

This same principle is used in the SharePoint news notification guide, where an explicit delivery marker prevents edits from resending the same news alert.

Reminders and escalation without a 30-day wait

A scheduled flow can query active records whose NextActionAt is in the past.

For each due record:

confirm it is still active;
check whether the response has already been processed;
send the appropriate reminder or escalation;
update NextActionAt or Status; and
write a small audit entry.

Keep the filter delegable and indexed when using a large SharePoint list. In Dataverse, select only the columns and rows required.

A scheduled reminder flow is not automatically reliable. Give it an owner, alerts and a reconciliation check so a week of failed runs is visible.

Why common “workarounds” fail

“Set the Delay to more than 30 days”

The flow run still reaches its 30-day maximum. The action value cannot override the service limit.

“Put each stage in a child flow”

Child flows are useful for reuse and separation. Calling one from a waiting parent is not documented as extending the parent run’s 30-day duration. To cross the boundary, persist state and start a later independent run.

“Chain a new copy of the flow every 29 days”

Blind chaining can duplicate requests, lose correlation and create an unbounded process. If a later run is required, start it from explicit state and make the handoff idempotent.

“Read the approval tables and compare numeric status codes”

Undocumented codes are brittle and hard to review. Use Microsoft’s documented long-running pattern and supported records/actions, and store your own named business status separately.

“Move it to Azure Functions or Logic Apps”

Those can be valid platforms for different requirements, but migration is an architecture and ownership decision:not a casual way to dodge one flow limit. Confirm identity, cost, monitoring, support skills and the product’s own duration model.

Monitoring and ownership

For every long-running process, answer:

Who owns the flow and its connections?
Who owns the business queue?
How is a failed run detected?
How do you find items with no activity past their deadline?
Can a support person resume, cancel or repair one process safely?
What happens when an approver or maker leaves?
How long must the audit record be retained?

Run history alone is not the business audit. It is time-limited operational evidence. Store the required business outcome and timestamps in the governed system of record.

Test matrix

Do not publish after one happy-path approval.

Test	Expected result
Approve normally	Business record completes once
Reject normally	Rejection path completes once
No response by reminder date	One reminder and new next-action time
No response by expiry	Visible expired status and owner notification
Duplicate response/trigger	Second run exits without duplicate effects
Flow fails after sending approval	Reconciliation identifies incomplete state
Approver account unavailable	Escalation or reassignment path works
Owner connection expires	Monitoring alerts a named operator
Process is cancelled	Later responses cannot reopen it accidentally
Two runs update the same record	Version/idempotency guard prevents corruption

Use non-production data and short test timeouts. Record the environment, flow versions and expected state transitions.

Frequently asked questions

Can a Power Automate approval wait longer than 30 days?

Not inside one waiting cloud-flow run. Microsoft documents a Dataverse-backed two-flow pattern for approvals that might exceed 30 days.

Does a child flow reset the 30-day limit?

Not for the waiting parent. Child flows help organise logic, but they are not a documented extension to a parent run’s duration. Persist state and use a later independent run when the process crosses the boundary.

Can SharePoint replace Dataverse for long-running approvals?

SharePoint can hold durable business-process state, reminders and correlation data. Microsoft’s documented pattern for an approval itself lasting beyond 30 days uses Dataverse. Do not claim a SharePoint tracking list changes the Approvals service contract.

Is run-history retention the same as run duration?

No. Microsoft currently documents both as 30 days, but one limits how long a run can execute and the other concerns stored run history.

Build flows that survive real delays

The Power Automate Builders Space focuses on approvals, failure paths, monitoring and the ownership decisions that quick flow demos leave out.

Microsoft sources used

Source boundary: Microsoft documents the 30-day run duration and the Dataverse-backed two-flow pattern for long-running approvals. The wider state model, reminders, idempotency and reconciliation sequence are Collab365’s operational design guidance and must be adapted and tested in the target environment.