A purchase request has been emailed to a manager. The manager is away, the requester assumes it is progressing, and the flow is still waiting. Sending an approval is only one part of a reliable business process. Someone must own the deadline, the exception and the final business action.
For UAE teams using Power Automate for purchases, document reviews or internal requests, design the “no response” route before rollout. The objective is to make stalled work visible while preserving approval authority, not to treat silence as permission.
Define who can decide and when
Start with a short business rule agreed by the process owner. Specify who can approve which request, whether one decision is enough or every nominated person must respond, and what happens when the usual approver is absent. A substitute must have the required authority; copying a colleague into an email does not establish that authority.
- Who owns the request until a decision is recorded?
- When should a reminder be sent, and when should the request become overdue?
- Who may reassign, cancel or resubmit it?
- Do weekends, public holidays or overseas working hours affect the deadline?
- What changes to the request require a fresh approval?
For example, a procurement team could agree that an unanswered request moves to an exception queue for an authorised supervisor to review. That is a proposed process, not a default Power Automate feature. Build and test the routing explicitly, including the organisation's own working calendar.
Keep a request record outside the notification
Give each request a stable identifier and maintain its business status in an agreed data store, such as a suitable SharePoint list or Dataverse table. Include the requester, current owner, submitted time, due time, request version, approval reference and final outcome. Select the store around access controls, audit needs and licensing.
A notification is a route to the decision, not the complete record. A reviewer should be able to tell what they are approving and whether it is still the current request. If the amount, supplier or document changes, define whether the earlier request is cancelled and replaced. Preserve the connection between the decision and the exact version reviewed.
ITZ's workflow automation service can help turn these rules into a scoped process with exception handling. Plan Your Approval Workflow Review using one real workflow and a description of where it stalls.
Handle timeouts as a business outcome
Microsoft's cloud-flow error guidance recommends explicit approval expiration and a timeout branch. Cloud-flow runs have a maximum duration of 30 days; that is a platform limit, not a sensible deadline for every request. Microsoft's approval known-issues page separately warns about a 28-day approval wait and abandoned approvals remaining in the action center after a waiting flow fails.
Choose a business deadline comfortably inside the applicable limits and test the actual action configuration. Configure the timeout path to mark the request overdue, notify the responsible owner and prevent downstream execution. Also define how obsolete approvals will be cancelled or reconciled. Do not assume a failed flow automatically removes its approval request.
For processes that genuinely need longer waits, Microsoft documents a Dataverse-based long-running approval approach that separates request creation from response processing. Assess permissions, connectors, licences and operational ownership before selecting that architecture. Increasing a timeout alone does not remove a flow's maximum run duration.
Separate approval from successful execution
“Approved” and “purchase order created” are different states. If an approved request must update an ERP, create a separate processing status and record the resulting document identifier. A connection failure should leave visible work for recovery, not make staff guess whether the order exists.
Before retrying, check the stored request status and destination reference. The guide to safe integration retries explains stable identifiers and duplicate prevention. Where the workflow crosses systems, scope the API integration as part of the design instead of assuming a connector guarantees the business outcome.
Apply the same discipline to late responses: once a request is cancelled or superseded, a response to its old approval must not authorise the new version. Check current business state before continuing to the consequential action.
Test the awkward cases before rollout
- Approve and reject a normal request, confirming the correct business status and notification.
- Leave a request unanswered and verify the reminder, timeout and owner notification.
- Make the approver unavailable and test the authorised reassignment procedure.
- Cancel or revise a pending request, then attempt to respond to the old approval.
- Simulate a failed downstream connection and verify that recovery does not create duplicate records.
- Confirm a support owner can inspect failures and maintain connections when the original flow creator is absent.
Use sample requests and a test destination so the exercise cannot issue a real order. Ask the process owner to sign off the outcomes, not simply whether a notification arrived. Keep an exception queue with an assigned owner and review routine; technical alerts without a responsible person still leave work stranded.
Plan your approval workflow review
Give ITZ the process steps, decision roles, usual waiting time and systems updated after approval. Request a scope covering deadlines, authorised handover, persistent status, failure recovery and acceptance tests. One well-defined process is a useful starting point before extending automation across departments.
