Governance First Power Automate Approvals for Professional Firms

Before building a Power Automate approval, confirm the environment, licences and approver permissions. Then map the decision owner, response path, timeout handling and audit record for one test flow.

TL;DR:

• Check the environment, database, permissions and licensing against current Microsoft documentation and the connectors in the test flow.
• Test the intended approval sequence and any repeated approver roles before using it with live requests.
• Check how custom responses appear in each chosen channel and what happens when the response list does not fit.
• Confirm current runtime and approval limits; plan and test how the request survives a timeout or a delayed response.
• Proper governance includes owner attribution, audit trails, and careful planning to prevent orphaned or unaccountable approvals as workflows scale.

Table of Contents

• What do you need before building approvals in Power Automate?
• What do the approval actions in Power Automate actually do?
• How do you create an approval flow in Power Automate?
• How do you set up sequential approvals in Power Automate?
• Custom responses, Teams cards and Outlook button limits
• How do you test and manage long-running approvals?
• What limits and errors should you plan around?
• A governance checklist for safe approval automation
• What breaks most approval workflows in practice?
• Get help designing approval workflows that hold up under scrutiny
• Sources
• FAQ

What do you need before building approvals in Power Automate?

Before adding an approval action, check the database and environment requirements for that action. Confirm whether provisioning is needed, who can perform it and how the setup will be tested.

Use Microsoft’s approvals documentation to check the prerequisites, then confirm the licence and connector coverage for your actual flow. Do not infer entitlement from the presence of another Microsoft product in the tenant.

Before you build anything, confirm the following:

• Your environment has a provisioned Dataverse database, or you have admin rights to trigger provisioning.
• Your licence tier includes the connectors your flow will use, not just Power Automate’s core plan.
• Non default environments have the Approvals User Dataverse security role assigned to anyone who needs to create or respond to approvals.
• Guest users are checked against your tenant’s external sharing rules, since guest access to approvals can behave inconsistently.
• You have decided between the new designer and the classic designer, since the interface and available triggers differ slightly between the two.

Resolve setup gaps before the first test. If a test fails, use the run history and error details to identify the cause rather than assuming it is licensing.

What do the approval actions in Power Automate actually do?

Choose the approval action by the behaviour you need: whether the flow should continue after creating a request or wait for a response. Confirm the available actions and current behaviour in Microsoft’s documentation.

Create an approval starts an approval request without waiting for a response, letting the flow continue immediately. Use this when you need to fire off a request and handle the response asynchronously, elsewhere in the flow or in a separate flow entirely.

For a flow that must branch on the decision, evaluate “Start and wait for an approval” and test how it waits, returns responses and handles an unresolved request.

Wait for an approval pauses execution for an approval that a separate action already created, useful when the creation and the waiting happen in different parts of a more complex flow.

Layered on top of these actions are the approval types themselves, and each behaves differently:

• Everyone must approve: every named approver has to respond before the flow moves on, useful for compliance sign off where one dissenting voice should block progress.
• First to respond: the flow proceeds as soon as any one approver answers, ideal for time-sensitive requests with interchangeable approvers.
• Custom responses: you define response labels beyond simple Approve/Reject, useful for nuanced outcomes such as “Approve with conditions.”
• Sequential: approvers respond in a defined order, one after another, rather than simultaneously.

The approvals connector reference notes that response values are case-sensitive in some downstream conditions, so a condition checking for “Approve” will not match a response of “approve” unless you normalise the text first. Pick custom responses when Approve/Reject genuinely doesn’t capture the decision you need recorded, not by default, since more response options mean more condition branches to maintain later.

How do you create an approval flow in Power Automate?

Building a working approval flow follows a predictable sequence, and the step-by-step tutorial from Microsoft uses a vacation request scenario to demonstrate exactly this pattern.

• Choose or build a trigger. A SharePoint “When an item is created” trigger works well for most business scenarios: pick the site and list, and make sure the list has the fields your approval will reference (requester name, amount, category, and so on).
• Configure the chosen approval action with a specific request title, authorised reviewer and decision evidence. Test formatting, links and response handling in the actual channel. The meeting-notes link is contextual reading, not approval-action documentation: how to automate meeting notes
• Add a Condition action that checks the dynamic value Responses Approver response equals “Approve.”
• Configure the True branch to send a confirmation email and update the source SharePoint item’s status column to “Approved.”
• Configure the False branch to send a rejection notice and update the status column to “Rejected,” including the approver’s comments if you captured them.
• Save and test the flow manually, then check that the pending approval appears correctly in the approvals centre before relying on it in production.

Use yourself as approver and a dummy record for the first test. Check the run history, the request’s visibility and the response record; do not diagnose a missing notification from elapsed time alone.

Common test failures trace back to three causes: the assigned approver’s email doesn’t match an active account, the trigger’s list permissions block the flow’s service account, or a dynamic value from the trigger step wasn’t actually populated when the record was created. Check the flow’s run history for the specific action that failed rather than guessing.

How do you set up sequential approvals in Power Automate?

Sequential approvals route a request through approvers one at a time, each seeing the request only after the person before them has responded. You configure this by selecting the Sequential approval type inside “Start and wait for an approval,” then adding each approval step in the order you want them actioned, as detailed in Microsoft’s guide to setting up sequential approvals.

A common real-world pattern looks like this:

• Step one: the requester’s line manager reviews and approves, often using a dynamic manager token pulled from Azure AD rather than a hardcoded email, so the flow adapts automatically as staff change roles.
• Step two: for spending above a defined threshold, the request routes to finance for final sign off, keeping day-to-day approvals fast while high-value cases still get proper scrutiny.

Test what happens if the same person occupies two roles in the intended sequence. Confirm the supported configuration and decide how the flow should handle that overlap before relying on the chain.

Name each step clearly, “Line Manager Review” and “Finance Sign Off” rather than “Approval 1” and “Approval 2,” because sequential chains get difficult to audit later if the step names don’t describe what actually happened.

Custom responses, Teams cards and Outlook button limits

Custom responses let approvers pick from labels you define, rather than a plain Approve or Reject. Decide upfront whether you need wait for one response or wait for all responses, because that setting changes whether the flow proceeds after the first answer or holds until every named approver has replied.

Check Microsoft’s current limits for custom responses in Outlook and other chosen channels. Test both the visible choices and the route to the approvals centre before using a long response list.

• Keep custom response labels short and unambiguous, since they render as physical buttons in email and Teams.
• If the response list does not fit the channel, define and test another supported route, such as the approvals centre.
• Use Teams only where the intended approvers can see and respond to the request. Test notification and response handling rather than assuming it improves response rates.
• Reserve email as the primary channel when you need a durable, searchable audit trail outside the Power Platform’s own logs.

For regulatory sign-off, agree the required record with the control owner. Test retention, export and access for the chosen channel; do not assume auditors prefer email or that an email alone is a complete audit trail.

How do you test and manage long-running approvals?

Test every approval flow manually before switching on the trigger for live data, then run it again with a genuinely awkward test case (a blank field, a rejected response, a slow approver) to see how the branches behave. Confirm the pending item appears correctly in the approvals centre, since a flow that runs without error can still fail silently if the approval record itself never surfaces there.

If a request may remain open beyond a flow’s supported runtime, verify the current limits and design a persistent request record with a supported continuation path. Test delayed responses, duplicate handling and recovery before live use.

• Cancel a stuck approval directly from the approvals centre, which stops the flow waiting on it without deleting the underlying record.
• Reassign approvals to a different approver when the original is unavailable, but only users with the right Dataverse role or ownership on that record can do this, not any flow editor.
• Capture a run log entry every time an approval is created, resolved or reassigned, since this becomes your evidence trail if a decision is ever questioned later.

What limits and errors should you plan around?

Check the connector and connection limits for the planned volume. In a bulk test, capture throttling responses and verify how retries avoid duplicate approvals.

Recipient formatting causes a disproportionate share of support tickets. The Assigned to field expects valid email addresses in a specific format, and guest users or shared mailboxes sometimes fall outside what the connector accepts, per the connector reference documentation.

Oversized payloads are the other quiet failure mode: a custom response list with too many options, or a Details field carrying huge amounts of Markdown, can push an approval past size limits and cause the action to fail without an obvious error message.

Work through this checklist when a flow misbehaves:

• Confirm the account running the flow has the correct Dataverse role and an active licence.
• Check every dynamic value populated correctly at the point the approval was created, not just at design time.
• Look for throttling errors in the run history if approvals are created in bulk.
• Verify recipient email formatting, especially for guest or shared accounts.
• Check whether a timeout, rather than a genuine failure, is why a long-running approval never resolved.

A governance checklist for safe approval automation

Map who makes the decision, the evidence they need and who owns a stalled request. Keep that ownership visible after the builder changes role. Pattrn Data’s governance guidance is service context, not evidence about how frequently this problem occurs.

Start with a small, controlled pilot rather than automating every approval process at once. One flow, one clear owner, one measurable outcome, then expand once you know it holds up under real use.

• Keep human review in place for any approval step where judgement, not just data, decides the outcome.
• Persist approval records in Dataverse whenever retention, traceability or long-running timelines matter, not only when a flow technically requires it.
• If Copilot or another AI tool suggests wording, routing or a recommended decision inside an approval flow, treat that suggestion as an input for the human approver to weigh, never as the decision itself.
• Build the audit trail into the flow from day one, not retrofitted after the first audit request arrives.

Pro Tip: Name every approval action after the decision it represents, not the system it touches. “Client Onboarding Sign Off” tells an auditor more in six months than “Approval 3” ever will.

Pattrn Data’s Medical Survey Copilot case study shows this approach applied in a regulated, document-heavy setting, where approval gates and evidence capture sit at the centre of the workflow rather than bolted on afterwards.

What breaks most approval workflows in practice?

A flow can run correctly and still leave a request unowned. Test the absence, escalation and handoff paths as well as the approval and rejection branches.

Notifications matter more than most designers give them credit for. An approver who doesn’t know a request is waiting hasn’t refused it, they’ve simply never seen it, and a flow that can’t distinguish between those two outcomes will frustrate everyone involved.

Resist the urge to automate every approval process across the business in one project. A small pilot, measured properly, teaches you more about where governance actually breaks than a comprehensive rollout ever will.

Rohit

Get help designing approval workflows that hold up under scrutiny

If the approval design is unclear, map the decision owner, evidence and exceptions before building. Pattrn Data’s AI workflow automation can support that scoping; the flow still needs its own testing and acceptance decision.

If your firm is looking at Copilot, Dataverse or approval-led automation and wants a clear-eyed view of where the risk actually sits, an AI readiness assessment is the sensible next step. It maps your current workflow, flags where governance gaps sit, and gives you a controlled pilot to start from rather than a big-bang rollout. Book an assessment and get a plan you can actually defend to a client or a regulator.

Recommended

• How should professional services firms connect AI governance and workflow controls
• What ethics and review rules should a professional services firm apply when automating client work
• How should a firm decide which AI tools are approved, including risk tiers, for client work
• What client-data boundaries should a professional services firm maintain when using AI