The report always arrives the same way. Somebody submitted a leave request, or a purchase order, or a document for sign-off. It went to the approver. Nothing came back. Three weeks later they ask what happened, and when you open the flow run history there is no failure, no error, no red icon — just a run marked as cancelled, and a request that no longer exists anywhere in the process.
This is not a bug in your flow. It is a documented platform limit behaving exactly as specified, and the reason it catches people is that the documentation describes it in terms that sound irrelevant when you are building.
What the limit actually is
A Power Automate flow run has a maximum duration. For most licensing tiers that ceiling is thirty days. When a run exceeds it, the run terminates. Not fails — terminates. Any action waiting inside that run stops waiting, and any state held only in the run’s memory is gone.
Now consider how almost every approval tutorial tells you to build an approval:
Trigger: item created ↓ Action: Start and wait for an approval ↓ Condition: outcome = Approve? ↓ Update item / send notification
The second action is the problem. Start and wait for an approval does what it says: the run sits open, holding the process in memory, until a response arrives. In a demo the response arrives in forty seconds. In an organisation where the approver is a department head who takes two weeks of leave in August, it does not.
Why it looks like nothing happened
A terminated run is not an error condition, so it does not trigger the failure notifications you have configured. It does not appear in the analytics you check. The approval record in the Approvals centre may still exist and still look actionable, which is the genuinely cruel part — an approver can open it, click Approve, and receive no indication that the flow which was listening died two weeks ago.
Silent failure is the worst kind, because the process appears to be working right up until somebody asks a question.
The fix is to stop waiting
Instead of one flow that creates an approval and then waits, build two flows that communicate through a SharePoint list.
Flow A — create
- Triggered by the business event
- Creates the approval using
Create an approval, which returns immediately rather than blocking - Writes the approval identifier, the item reference and a status of Pending to a tracking list
- Ends. Run duration measured in seconds.
Flow B — respond
- Triggered by the approval response arriving
- Looks up the tracking list record by approval identifier
- Applies the outcome and updates the status
- Also ends in seconds.
The waiting now happens in a SharePoint list rather than inside a running flow. Nothing is holding state in memory, so nothing can time out. An approval can sit for six months and still resolve correctly.
What you get for free
Decoupling turns out to be the right architecture for reasons beyond the timeout:
- Reminders and escalation become a third scheduled flow reading the tracking list. With the blocking pattern this is awkward; here it is trivial.
- Reassignment is possible, because the pending state is a list item somebody can edit rather than a variable inside a run.
- Reporting comes for free. Average approval time, current queue depth, who is sitting on requests — all queryable, because it is all in a list.
- Recovery is possible. If something goes wrong you have a record of exactly which approvals were outstanding.
When the simple pattern is fine
None of this means the blocking pattern is always wrong. If your approval genuinely resolves within hours — a two-person team, a same-day sign-off, an internal notification that is nice-to-have rather than load-bearing — the simpler flow is easier to read and easier to maintain. Complexity you do not need is its own cost.
The judgement is about consequence. Ask what happens if this specific approval silently disappears. If the answer is that somebody notices in a day and resubmits, build it simply. If the answer is that a payment is missed, a contract lapses, or a compliance deadline passes unrecorded, decouple it.
In our experience most organisations discover which category they are in the hard way, roughly four months after go-live.