A Power Automate approval workflow is useful when a request needs a decision, a record of who approved it, and a predictable next action. The reliable pattern is simple: capture the request, start and wait for an approval, branch on the response, then write the outcome back to the source system. Microsoft documents the Start and wait for an approval action as the core step for approval processes across services such as SharePoint, OneDrive, Dynamics 365, and other business systems.
Plan the request intake first
Pick a structured request source
Start with a structured request source, not the approval email. A SharePoint list, Microsoft Form, Dataverse row, or file library gives the flow a stable record to update after the decision. Email can start a flow, but it is harder to validate fields, prevent duplicates, and show final status to the requester.
Define the required fields before building the flow. For a purchase request, that might include requester, amount, vendor, business reason, budget code, and attachment. When my approval flows fail later, the root cause is often that the request form allowed vague data into the process.
Choose the approval request trigger
Create an automated cloud flow from the event that represents a new request. For SharePoint, that may be When an item is created. For Forms, it may be a new response followed by a response details action. The trigger should fire once per real request, not once per edit or notification.
If the flow does not start consistently, fix trigger problems before adding approval branches. Approval logic cannot repair a request that never enters the workflow. Test the trigger with one clean request and confirm a run appears in history.
Build the approval decision path
Add the core approval action
Add Approvals >> Start and wait for an approval after the trigger and any lookup steps. Choose the approval type that matches the business rule: first responder, everyone must approve, or custom responses where appropriate. Write the approval title so approvers can recognize the request without opening the source system.
Include the key request fields in the approval details. Approvers need enough context to decide, but not a wall of copied list data. I usually include the request ID, requester, amount or document name, deadline, and a link back to the source record.
Route each approval outcome clearly
After the approval action, add a condition that checks the response outcome. If approved, update the source item, notify the requester, and continue the business process. If rejected, write the rejection status and comments back to the source item, then tell the requester what changed or what to resubmit.
Do not leave the result trapped inside the approval center. The original request needs a final status because that is where managers, requesters, and auditors will look later. A clean status field also prevents duplicate follow-up emails.
Record approver comments with status
Approval comments are operationally important. They explain why a request was rejected, why an exception was allowed, or what condition applies to the approval. Store those comments on the request item or in a related log instead of relying only on the approval email.
If for some reason the intake starts in Outlook, make sure to track Outlook requests so the process does not depend on one person’s mailbox. Approval workflows are easier to support when the final record lives in a shared system.
Make approval workflows easier support
Avoid brittle hard-coded approver lists
Hard-coded approver addresses are acceptable for a small workflow, but they become expensive when managers change. Consider storing approvers in a SharePoint list, using a manager lookup, or routing by department, amount, or request category. The more often the routing changes, the less it belongs inside the flow definition.
Test what happens when an approver is missing, duplicated, or out of office. Power Automate will wait for the configured approval logic, so your business process needs a timeout, escalation, or manual fallback if decisions cannot wait forever.
Add reminders after routing works
Reminders are useful after the basic approval works. Build the first version without reminder loops, prove that approvals are created and responses are captured, then add reminder or escalation logic. Otherwise, you can bury a routing problem under a pile of reminder emails.
A common pattern is to use a delay, check whether the request is still pending, and send a reminder only if no outcome has been recorded. Keep the reminder short and include the same source record link. My rule is that reminders should help the approver act, not shame them for a broken process.
Test every approval branch separately
Run one approved request and one rejected request before calling the flow finished. Confirm the source item updates, requester notification arrives, approver comments are stored, and no branch sends contradictory messages. If there are attachments, test a request with and without them.
Use real-looking test data. A request called “test” with no amount or owner does not prove the workflow will work on Monday morning. Good test records expose missing fields, bad links, and confusing approval titles early.
Document workflow ownership and escalation
Assign an owner for the workflow itself, not only the approval request. Someone should know who can change routing, where failed runs are reviewed, and how exceptions are handled when an approver is unavailable. That ownership note belongs in your process documentation because Power Automate flows often outlive the person who first built them. For direct channel notifications instead of an approval response, use this workflow to post an automated Teams update.
Protect approval history from ambiguous outcomes
A reliable change starts with a controlled comparison, not a long sequence of resets. Handle timeout, cancellation, rejection, and reassignment explicitly. Write down the account, client or device, and exact symptom so that later tests use the same conditions. Change one variable at a time; several simultaneous fixes can hide the real cause and make the problem return.
Run a focused comparison
Use group or configuration-based approvers rather than personal addresses. Repeat the test with a simple sample that contains no confidential or business-critical data. If the sample works, compare permissions, file location, policy, and content with the failing case instead of reinstalling the whole product.
Test concurrent requests so one response cannot update the wrong record. Keep the original configuration or data until the new result has been checked. When a setting is unavailable, grayed out, or labeled as organization-managed, capture that message and ask the responsible administrator to review the policy.
Verify the result in normal use
undefined. Confirm the result after closing and reopening the relevant app, then repeat it from the normal user workflow rather than only from an administrator or owner account. A successful one-time test is not enough when synchronization, scheduled refresh, or another device is involved.
If behavior differs across clients, record the app version, account type, time of the test, and where the expected result appears. Use that evidence to decide whether the remaining fault is local, account-specific, data-specific, or service-side. This keeps troubleshooting narrow and protects working settings while support investigates the correct layer.
Finally, explain the intended outcome to another user and have that person repeat the shortest safe test. Their result can reveal hidden owner privileges, cached state, or assumptions about where data is stored. Preserve screenshots of error messages only after removing names, addresses, document content, and other private information.
Power Automate approval questions answered
What action creates approval requests?
Use Start and wait for an approval from the Approvals connector when the flow should pause until a decision is made. The action returns the outcome and response details for later conditions.
Where can approvers submit responses?
Microsoft says approvers can respond from email, the Power Automate approvals center, or the Power Automate app. If an email is missing, check the approvals center before assuming the flow failed.
Should one approver be enough?
Use one approver for simple operational requests. Use multiple approvers when policy requires consensus, parallel review, or escalation by amount or category. The approval type should match the written business rule.
A good approval flow is easy to audit: the request enters once, the decision is captured, the source record is updated, and every stakeholder can see the final state.