A Power Automate approval becomes dependable when the SharePoint request itself shows who must act, by when, and what has been decided. Email, Teams and the Approvals centre are useful places for someone to respond, but staff should not have to search them to find out whether a purchase, document, booking or customer request can proceed.
For most power automate approvals, begin by designing the request record and decision rules before adding the approval action. A flow that sends a card to an approver but leaves the list item marked “New” has only moved the uncertainty elsewhere.
Make the SharePoint item the record people work from
A SharePoint list is often a sensible starting point for a repeatable internal request. One item represents one business case: for example, a manager submits a request to approve a supplier invoice outside the usual spend limit.
The list needs more than the form fields submitted by the requester. Add fields that show the state of the work after submission:
- request ID, requester and submission date
- business status, such as Submitted, Validating, Awaiting approval, Returned for information, Approved, Rejected, Overdue, Escalated, Cancelled and Completed
- current decision owner and, where relevant, the current approval stage
- due date, reminder date and escalation state
- final outcome, decision date and approver comments
- the approval ID, so the workflow can identify the approval it created
Treat SharePoint as the business record and Power Automate as the decision process: write the current status, named approver, decision date, comments and escalation state back to the request itself.
Give requesters a view showing their open requests and their current owner. Give approvers a view filtered to requests assigned to them and due soon. Give an operations manager a view of overdue and escalated cases. Those views answer ordinary operational questions without requiring anyone to understand the flow.
For a simple one-stage decision, fields on the main list item may be enough. If a request can pass through finance, operations and a director, or can be returned and resubmitted, keep a related approval-history list as well. Each row can record the stage, named responder, response, timestamp and comment. That preserves the earlier decision when the request moves on or is reworked.
Choose the approval pattern to match the actual policy
Power Automate supports first-to-respond, everyone-must-approve, sequential approvals and custom responses. The correct choice follows the authority to decide, not who happens to need visibility.
Use first to respond only where any one member of a properly authorised group may make the decision. A finance duty manager rota is a reasonable example. It is not suitable where procurement and finance must both approve.
Use everyone must approve when every named reviewer must sign off. Use a sequential process when the order matters, such as a line manager confirming the business need before finance assesses budget. Custom responses can be useful for choices such as “Approve”, “Return for information” and “Reject”, provided each response has a defined next step.
Write these rules down before building. For each stage, name the accountable role, a delegate or escalation role, the target response time and the authority to cancel or reassign a request. Do not make the requester responsible for chasing a decision that belongs to an approver.
From submitted request to a decision people can follow
Build the flow around clear state changes
A basic SharePoint approval workflow can start when a submitted request is created, validate the information, set the status to “Awaiting approval”, write the named approver and due date, then send the approval. Microsoft’s documented pattern can update the SharePoint item with the approver’s response and comments after a decision.
For short, straightforward requests, Start and wait for an approval is usually the clearest action. It creates the approval and pauses that flow run until it is answered. Once the response arrives, update the request and follow the appropriate path: notify the requester, create the next stage, create a task, or mark the work complete.
Use Create an approval when the process needs to continue without waiting, or when reminders, escalation and response handling need to be separated. Store the approval ID and current state on the request so later steps operate on the same case rather than creating another approval.
If an approval can remain open for more than 30 days, do not make one waiting flow run the sole controller of the process. Microsoft advises a split design, with one flow creating the approval and another acting on its response, using Dataverse for approval storage. That is a useful point to reassess whether SharePoint alone is the right home for the process.
Send reminders without creating competing approvals
A reminder is a message about an existing decision, not a new decision request. A scheduled flow can find records where the status is “Awaiting approval”, the due date is approaching or passed, and the request has not been cancelled or completed. It can notify the current owner, then update a last-reminded date so it does not send the same reminder repeatedly.
Agree the policy first. For example: remind two working days before the deadline, mark the request overdue on the deadline, then notify the escalation owner after one further working day. Whether the original approver retains the decision, a delegate takes it over, or a manager reassigns it is a business rule. The flow should record that change on the request and in the history.
Handle the less tidy outcomes deliberately. “Returned for information” should name the requester or staff member who must respond and should stop the approval clock until the request is resubmitted. Cancellation should close or cancel the outstanding approval and prevent further reminders. If an approver is absent, reassignment should be visible rather than silently changing the recipient.
When an Approval Goes Quiet
The request waits, an approver is absent, or the decision email is missed.
Remind the current owner, then record any visible reassignment or escalation on the request.
Record the response, comments and next action on the same request, not in a lost email.
Prevent duplicate runs when the flow updates SharePoint
The SharePoint trigger “When an item is created or modified” fires whenever an item changes. If the flow updates the same item to write “Awaiting approval”, it can start itself again and send duplicate approvals unless the trigger is guarded.
A practical approach is to use an explicit submission field or status transition. The requester submits a draft by setting it to “Submitted”; the initiation flow only runs for that condition and then changes the status. Depending on the design, changed-column logic, trigger conditions or a separate initiation flow may also be appropriate. Test resubmission, edits while awaiting a decision, flow retries and an administrator correcting a list field. These are the situations in which apparently sound flows often create duplicates.
Deploy an approval process that survives staff changes
Once approvals control spend, customer commitments or operational work, the flow needs an owner beyond its original maker. Use solution-aware flows and connection references so the process can be moved and managed properly between environments. Review who owns the connections, who can alter routing rules, who monitors failed runs and who can take over when a role changes.
Keep request details and approver comments visible only to people who need them. A notification can expose information more widely than the SharePoint item if recipient groups are chosen carelessly. Conditional Access treatment also needs to be consistent across SharePoint and Power Automate, or users may encounter authentication failures when trying to run the process.
If several approval types route into a CRM, finance package or document system, the design is usually beyond a copied template. It needs a clear record model, routing rules and ownership that match the work people are actually accountable for. That is the point at which automation and integration work should focus on the hand-offs between systems rather than simply adding more notifications.
Plan an approval workflow people can follow
Show ZappFlow the form or SharePoint list that starts the request, the people who must approve it, the deadline rules and what needs to happen after approval. We can map the gaps and build a workflow that records every decision in the right system.