Almanac
Microsoft/power-automatePower Platform

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.

power-automate/06-approvals-and-human-in-the-loop/feature-approvals-reassignment-and-delegation.md
feature-approvals-reassignment-and-delegation.mdv1 · history
CurrentApplies to Cloud flowsUpdated last monthSource Microsoft Learn ↗

What it does

Reassignment lets an approver hand a request they've received to somebody else. Delegation — routing requests away before they land, because the approver is out — isn't in the connector; it comes from the Approvals Kit or from logic you build in the flow.

Key facts

  • An approver reassigns from Approvals in the Power Automate portal: hover the request, three dots, Reassign, name the new assignee.
  • Reassignment is controlled per approval action by the Enable reassignment parameter. Turn it off and approvers can't hand requests on.
  • The requester cannot reassign. As the maker or requester your only option is to cancel the request from the Sent tab and change the Assigned to value in the flow.
  • Cancelling is available from Approvals > Sent while the request is unanswered.
  • Native delegation doesn't exist in the connector. The Approvals Kit ships an Approvals Manager app with Out of Office Settings where a user sets a date range and a person to delegate to; new requests inside that window route to the delegate.
  • Kit delegation only fires while out-of-office is switched on and the current time falls inside the range set. Outside either condition, nothing is delegated.
  • Users assigned an approval who aren't already in the environment get the Approvals User Dataverse security role automatically so their response is recorded.
  • Reassignment and cancellation are visible in the approval's Dataverse history, so the audit trail survives the handover.

When to use / skip

Leave reassignment on by default for most business approvals — it's how real organisations cope with holiday, handover and the wrong person being asked. Turn it off deliberately where the approver's identity is the control: anything with segregation-of-duties, financial delegation limits or regulatory sign-off behind it. If a client needs proper delegation with date ranges and an audit trail, deploy the Approvals Kit rather than reinventing it, and budget for it as a solution to deploy and support rather than a checkbox.

Configuration decisions

  • Whether reassignment is enabled per approval action, decided by control requirement rather than left at default.
  • Whether delegation is handled by the Approvals Kit, by resolving approvers from an out-of-office table at runtime, or not at all.
  • Who can see and act on other people's pending approvals, and through what — admins have no simple portal view of everyone's queue.
  • What happens to in-flight approvals when someone leaves, which is a process question before it's a technical one.
  • Whether the approver is resolved at run time from HR or Entra data, which is what makes mover and leaver handling work without touching flows.

Gotchas

  • Reassignment moves the request but not the flow. Downstream logic that assumes the original approver responded gets the new person's identity in the Outcome, and hardcoded name checks break.
  • A leaver's outstanding approvals don't go anywhere. The request sits assigned to a disabled account until the run hits its duration limit, and nobody notices until someone chases.
  • Admin visibility over pending approvals is thin. Answering "what's sitting with Dave" realistically means querying the Dataverse tables directly.
  • Kit delegation depends on the user having set their out-of-office correctly, in advance. People who leave suddenly never did.
  • Approvals raised through the Teams app live in the default environment, so any delegation solution deployed elsewhere doesn't cover them.

Consultant notes

  • Hardcoded approvers are the root cause of most leaver problems. Resolve approvers from a manager lookup or a role table and the mover and leaver case mostly handles itself.
  • Get the leaver process agreed with whoever runs joiners-movers-leavers, not just with the project sponsor. It needs someone to cancel or reassign outstanding items as part of offboarding.
  • Build the admin view of pending approvals early. It's cheap over the Dataverse tables and it stops the support queue filling with "where is my request".
  • Be clear with the client that delegation is a solution to deploy and own, not a product feature. That framing avoids a nasty surprise in the support handover.

Recheck if native delegation ever lands in the Approvals connector, or the Approvals Kit gets a significant release

Was this accurate?
Related
Approvals overview06-approvals-and-human-in-the-loopAdaptive cards in Teams03-connectors-and-integrationConnection references07-alm-and-solutionsApprovals in Teams and Outlook06-approvals-and-human-in-the-loopFlow sharing and ownership08-governance-and-securityDataverse connector and triggers03-connectors-and-integration