Almanac

Consultant KB for Microsoft Power Automate end to end: cloud flows, desktop flows and RPA, connectors and integration, AI and agent flows, process and task mining, approvals and human-in-the-loop, ALM and solutions, governance and security, licensing and capacity, monitoring and troubleshooting, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power Automate release plans, docs repo and product blog, plus the author's own consultant notes.

feature-approvals-overview.mdv1 · history
CurrentApplies to Cloud flowsUpdated last monthSource Microsoft Learn

What it does

The Approvals connector pauses a flow, sends a request to named people, and resumes when they respond. The request and every response are stored as Dataverse rows, which is what gives approvals their history, their reassignment behaviour and their surfaces in Teams, Outlook and the Power Automate action centre.

Key facts

  • Approvals is a standard connector. Any licence that grants Power Automate with standard connectors covers it — Power Automate plans, qualifying Office 365 licences, and Dynamics 365 licences with built-in Power Automate.
  • Everything lands in Dataverse. In a non-default environment the database is provisioned automatically the first time an approval flow runs, and the user running it needs an administrator role in that environment for provisioning to succeed. Subsequent makers need no elevated rights. The default environment already has Dataverse, so this doesn't apply there.
  • The core actions are Create an approval (fire and forget), Start and wait for an approval, Start and wait for an approval of text, and Wait for an approval. Two older Start-and-wait variants are deprecated.
  • Assignees can be given as email address, UPN or Entra ID object ID, separated by semicolons. Types can be mixed in one field.
  • Users outside the environment who get assigned an approval are automatically granted the Approvals User Dataverse security role, which is what lets their response persist to history.
  • Throttling on the connector is 50 approval-create requests per flow per 60 seconds and 500 non-create requests per flow per 60 seconds.
  • The flow creator is always shown in the approval details across every client. That's deliberate anti-spoofing and can't be changed.
  • Approval timestamps are always UTC. The Date Created field in emails can't be switched to local time.

When to use / skip

Use it whenever a process needs a named human to say yes before it continues and you want that decision recorded, findable and reportable. It's the right default for anything with an audit expectation. Skip it for pure notification — if nobody's decision changes what happens next, send a Teams message or an email and keep the flow moving. Also skip it where the client already has a mature approval system; two systems of record for approvals is a governance problem, not a feature.

Configuration decisions

  • Which environment approvals live in, given the Dataverse dependency and the fact that the Teams Approvals app always creates in the tenant's default environment.
  • Whether approvers can reassign, which is a per-action toggle on the approval.
  • Whether notifications go out at all, also a per-action toggle.
  • What the flow does if nobody responds — approvals wait indefinitely unless you build a timeout.
  • Whether the process needs approvals as the record, or approvals as the prompt with the real record elsewhere.

Gotchas

  • The first approval flow in a fresh non-default environment fails for anyone without an admin role, because it's the provisioning step that fails rather than the approval. It's a confusing first-day error.
  • UTC timestamps confuse business users every single time. The workaround is to convert the time yourself and put it in the Details field.
  • Approval attachments must have unique names within a request. Duplicates stop the notification being sent at all.
  • Custom-response approvals sent to a large group with "Everyone must approve" can fail outright on the size of the results field.
  • Nothing in the connector times out on its own. A flow waiting on an approval sits there until the run duration limit, and to the business it looks like the request vanished.

Consultant notes

  • Get the environment strategy decided before the first approval is built. Retrofitting approvals into a different environment means the history stays behind.
  • Push for a reporting view over the approval tables early. "Where is my request" is the single most common support call on any approvals rollout, and self-service answers it.
  • Warn clients that approvals history is per-environment and per-tenant. Anyone expecting one cross-tenant view of every approval is going to be disappointed.
  • Design the timeout and escalation behaviour in the first workshop. It's always needed and always forgotten.

Recheck if the connector limits change or the deprecated Start-and-wait actions are finally removed

Was this accurate?