Power Automate Approval Workflows: Design Patterns, Permissions, and Troubleshooting

Overview

Approval automation usually connects a business request to one or more reviewers, waits for a decision, and writes the result back to a system of record such as SharePoint, Dataverse, or another connected service. The design is straightforward only when the requirements are clear. Problems often appear later: a request is submitted twice, a reviewer cannot open an attachment, an approval remains pending after an employee leaves, or a flow records a decision without preserving enough context for an audit.

Before building, define four things: what starts the request, who must approve it, what happens after each response, and where the final decision is stored. Also decide whether the process is informational, operational, or sensitive. That classification can affect connector selection, access design, retention expectations, and the review needed when Microsoft changes a connector or approval experience.

Approval action patterns

These patterns are functional choices, not permanent labels. Interface names and connector behavior can change, so verify the available actions in the current Power Automate designer before implementing a production flow.

Business requirements template

• Request: What is being approved, and what business rule requires approval?
• Submitter: Who can create a request, and can the submitter approve their own request?
• Reviewers: Are reviewers fixed, selected from a field, or resolved through a manager or group?
• Decision rule: Is one response sufficient, or must all reviewers respond?
• Sequence: Can reviews run in parallel, or must one stage finish before the next?
• Deadline: How long should a request remain pending before escalation?
• Evidence: Which fields, comments, attachments, timestamps, and identities must be retained?
• Exceptions: What should happen if a reviewer is unavailable, a file is removed, or a connector fails?
• Ownership: Who monitors failed runs, changes the flow, and handles support questions?

Checklist by scenario

Creating a basic approval flow

1. Choose a trigger that represents a genuine submission event, such as a new item or a status change.
2. Capture a stable request identifier and use it throughout the flow.
3. Build a clear approval title and include the key decision fields in the approval details.
4. Set the assigned reviewers from a controlled source rather than accepting arbitrary addresses without validation.
5. Condition the next step on the returned outcome, not on whether the approval action merely completed.
6. Update the source record with the decision, comments, reviewer identity, and relevant timestamps.
7. Notify the submitter of both approval and rejection, using a message that explains the next action.

Handling parallel reviewers

Use a parallel or group-based pattern when reviewers can act independently. Define whether the first response ends the process or whether every reviewer must respond. If every response is required, decide how the workflow represents partial completion. A separate approval status such as Pending should remain visible until the decision rule is satisfied.

Validate that each reviewer has access to the approval and any linked records. A reviewer may receive the notification but still be unable to open the underlying SharePoint item, Dataverse row, or attachment. Test with a representative account rather than only the flow owner.

Building sequential approvals

Sequential approvals work when the process has stages, such as an initial business review followed by a financial or compliance review. Store the current stage in the source record. Start the next approval only when the previous stage produces the required outcome. If a stage is rejected, stop or route the process according to an explicit business rule instead of allowing later stages to continue.

For each stage, define a fallback for absence, reassignment, or an invalid reviewer. Do not assume that a manager lookup or group membership will always return a usable address. Include a validation step and a notification path for missing or ambiguous reviewer data.

Adding escalation and reminders

Escalation should be deliberate rather than an automatic second path that can create duplicate decisions. Record the original due time, send reminders according to the business requirement, and escalate only when the request is still pending. Specify whether the escalation replaces the reviewer, adds another reviewer, or alerts an owner while leaving the original assignment unchanged.

If a long wait is possible, separate the approval process from monitoring logic where practical. A scheduled review flow can identify overdue requests, but it must check the current status before sending another reminder or creating another approval.

Managing attachments

Decide whether the approval should contain a copy of the file, a secure link, or a reference to a document library item. Confirm that reviewers can access the selected location and that the file will remain available for the expected life of the request. Test file names, multiple attachments, large files, and deleted or moved documents. Store the attachment reference with the request so a later reviewer can understand what was approved.

What to double-check

• Permissions: The connection owner, submitter, reviewer, and approver group may have different rights. Test each role against the trigger source, approval record, linked data, and notification channel.
• Duplicate prevention: Use a unique request ID and check the existing status before creating an approval. A retry or repeated status update should not create a second active request.
• Concurrency: Consider what happens if two updates arrive close together. Where supported, configure concurrency deliberately and make the status update idempotent.
• Failure handling: Decide how to surface failed connector calls, invalid responses, throttling, and unavailable services. A flow that silently ends is difficult to operate.
• Audit data: Record the final outcome, decision comments, reviewer identity, and timestamps in a location that authorized administrators can search.
• Licensing and connectors: Review the connectors and capabilities used by the flow against the organization’s current licensing and environment rules. Treat licensing as a deployment check, not an assumption.
• Release impact: After a Power Automate or connector update, test the designer action, response values, attachment behavior, notifications, and run history fields used by downstream steps.

For identity-dependent approvals, review the organization’s access model alongside the flow. The Microsoft Entra ID Conditional Access design and testing guide can help teams assess how sign-in controls may affect users or automation administrators.

Common mistakes

Using the flow owner as the only operating identity

A personal account can make a prototype work quickly, but it creates an ownership and continuity risk. Document the connection owners, permissions, environment, and support process. Where organizational policy permits, use a managed operating model and test recovery when an owner is unavailable.

Treating rejection as an error

A rejection is normally a valid business outcome. Branch on the response and update the request accordingly. Reserve failure handling for technical problems such as a connector error or malformed data.

Allowing an empty reviewer value

An approval cannot be dependable if its recipient is optional or unresolved. Validate the reviewer before creating the approval and route missing data to an owner for correction.

Building reminders that create new approvals

Reminder logic should inspect the existing request and its current status. Creating another approval for the same request can confuse reviewers and make the final record difficult to interpret.

Testing only the happy path

Test approval, rejection, timeout, reassignment, duplicate submission, missing attachment, unavailable connector, unauthorized reviewer, and a flow rerun. Capture the expected record state for each case.

When to revisit

Review the workflow before seasonal planning cycles, organizational changes, major policy updates, and any change to the source system or approval rules. Also revisit it when Power Automate, an approval connector, Microsoft 365, or a connected service changes its interface or behavior.

At each review, use this short operational checklist:

1. Submit a test request from a normal user account.
2. Confirm the correct reviewer receives it and can open every required record and attachment.
3. Test the configured response pattern, including each custom outcome.
4. Verify that the source record contains the final status, comments, identity, and timestamps.
5. Check that reminders and escalation occur only for genuinely pending requests.
6. Review failed runs, long-running approvals, orphaned requests, and duplicate records.
7. Compare the connectors, permissions, and licensing assumptions with the current Power Platform configuration.
8. Record the test date, result, owner, and any required change.

Keep the requirements template, test cases, and release notes with the workflow documentation. That makes the approval process easier to update when the business changes and gives administrators a practical baseline for investigating future failures.