A timed-out flow run and an outstanding approval request are different states to inspect. Before resubmitting a failed run, identify whether an approval already exists and whether a person can still respond to it. Creating another request immediately can leave reviewers with competing instructions.
Start with the flow run identifier, approval identifier, source document and exact failed action. Record whether the timeout came from an action-specific setting or the overall run's limits. “Timed out” without that context is not enough to choose a safe recovery action.
Locate the approval that was actually created
Inspect the relevant run history and the approval center through an authorized account. Confirm the request title, assignee and identifier. Two requests with similar titles should not be treated as one simply because they concern the same document.
Microsoft's modern approvals guide describes approval creation and supported cancellation behavior. Use the actual request state to plan recovery. Do not assume stopping a run performs every business action needed to withdraw a request or notify its reviewers.
Preserve a response that already exists
If the reviewer responded before a later action failed, record that response and whether the business outcome was applied. Repeating the approval stage can ask for a second decision unnecessarily. The recovery owner should distinguish collecting the response from applying it to the source system.
Identify the reviewed revision
Check whether the source document changed while the request waited. A late response to an older revision may require a new review under the organization's rules. The mere existence of an approval response does not establish that it concerns the current content.
Check the relevant time limit
Microsoft's cloud-flow limits document run-duration constraints, including the limit relevant to long waiting actions. Read the current limits for the actual design. A business process that can exceed a run's supported duration needs an appropriate long-running architecture rather than a larger-looking timeout string.
| Observed state | Recovery question |
|---|---|
| Run timed out; request still outstanding | Should the existing request remain valid or be withdrawn? |
| Response exists; update failed | Can the approved outcome be applied without another request? |
| Document changed during waiting | Does the response still concern the intended revision? |
| No request was created | Can the failed creation step be retried safely? |
Decide whether to cancel, continue or replace
Have the process owner choose the intended business state. If a request is no longer valid, use the supported cancellation route available for that request and inform the participants through the approved workflow. If a replacement is required, link it clearly to the withdrawn or failed request.
Do not automatically approve or reject on a timeout unless that rule was explicitly designed and authorized. No response, a technical timeout and a human rejection mean different things and should remain distinguishable in the record.
Plan long-running approvals deliberately
The modern approvals documentation describes a separate approach for requests that may outlast the original run, using persisted approval data and separate response handling. Evaluate that architecture, its permissions and licensing with the application owner before changing production.
Keeping a flow waiting indefinitely is not a complete recovery strategy. Define request ownership, reminders, escalation, cancellation and the relation between the decision and document revision. These process decisions remain necessary even when the technical waiting mechanism changes.
Test recovery without real reviewer traffic
Use a pilot request with a short controlled timeout and harmless sample data. Test no response, a response before failure, a response after the waiting run ends and a deliberate replacement. Confirm how many approval identifiers exist and what reviewers can still do.
These are proposed acceptance cases, not a guarantee about every connector configuration. Record the actual results and revise the design when a request remains actionable after the process considers it closed.
Keep a compact operational register
Store the request ID, source item, revision marker, assignee, response state and recovery owner. Include the run ID without confusing it with the approval ID. This lets support connect the technical failure with the business request without preserving every email as the only record.
Our SharePoint approval workflow guide provides the broader design context. For a timeout incident, first identify the existing request and any response, then choose an authorized recovery path. A clean run history is not the same as a clear, consistent instruction to the people making the decision.
