100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
Programming

Approvals

Build sequential and parallel approval processes in Power Automate using the dedicated Approvals connector and custom responses.

IntegrationsIntermediate8 min readJul 10, 2026
Analogies

The Approvals Connector

The Approvals connector is a dedicated Power Automate and Power Apps service purpose-built for human decision points in a workflow, distinct from a plain Teams Adaptive Card because it persists approval requests as durable records visible in the Power Automate mobile app, the Approvals hub in Teams, and Outlook, regardless of whether the originating flow run is still active. Every approval created with 'Start and wait for an approval' or 'Start an approval' has a type: 'Approve/Reject - First to respond', 'Approve/Reject - Everyone must approve', 'Custom Responses - First to respond', or 'Custom Responses - Everyone must respond', and picking the right type determines both how many approvers must act and whether the flow proceeds on the first response or waits for all of them.

🏏

Cricket analogy: An approval persisting outside the flow's run is like a DRS review request logged with the third umpire's system, still tracked and resolvable even if the live broadcast feed temporarily drops.

Sequential vs Parallel Approvals

A single 'Start and wait for an approval' action with multiple assigned approvers and the 'Everyone must approve' type runs those approvers in parallel, all notified simultaneously; building a true sequential chain, where approver two only sees the request after approver one signs off, requires chaining multiple separate approval actions one after another, often with a Condition checking each stage's outcome before starting the next. This is a common design mistake: teams assume listing approvers in order in a single action creates sequential routing, when in fact the connector treats that list as parallel recipients, and the response outcome is aggregated based on the chosen type rather than respecting list order.

🏏

Cricket analogy: Sequential approval chaining is like a batting order where the next batter only walks in after the previous one is dismissed, versus parallel approval which is like all eleven fielders reacting to the ball simultaneously.

Reading Approval Outcomes

'Start and wait for an approval' returns an 'Outcome' dynamic value (typically 'Approve' or 'Reject', or the custom label chosen) plus an array of individual 'Responses', each including the responder's name, email, comments, and response date, which is essential for audit trails; loop over the Responses array with an Apply to each action if you need to log every individual approver's comment rather than just the aggregate outcome.

Custom Responses and Escalation

Beyond binary Approve/Reject, the 'Custom Responses' approval types let you define up to five custom response options (for example, 'Approve', 'Approve with conditions', 'Need more info', 'Escalate', 'Reject'), each with its own label, which the flow then branches on using a Switch action against the Outcome value. A common production pattern combines a time-based escalation with the approval: run 'Start an approval' (fire-and-forget) alongside a parallel branch that waits a set duration (say, 48 hours) using the 'Delay' action, and if the approval hasn't completed by then, send a reminder or automatically escalate to a backup approver, cancelling the original request with 'Cancel an approval' if needed.

🏏

Cricket analogy: Custom Responses beyond Approve/Reject is like an umpire's decision review offering Out, Not Out, or Umpire's Call, three distinct outcomes rather than a simple binary.

text
// Pseudocode for the parallel escalation pattern
Parallel branch 1: Start an approval (fire-and-forget), assigned to "primary.manager@company.com"
Parallel branch 2: Delay 48 hours -> Get approval responses -> Condition: Outcome is empty?
  If true: Cancel an approval (original request ID) -> Start an approval assigned to "backup.manager@company.com"

'Start and wait for an approval' blocks the flow run for as long as the approval remains pending, and like the Adaptive Card wait action, it is still subject to the tenant's maximum flow run duration; for approval processes with an uncertain or potentially long timeline, prefer 'Start an approval' (which does not wait) combined with a separate trigger, such as 'When an approval is completed' or a Dataverse row-change trigger, to resume the process asynchronously.

  • The Approvals connector persists requests as durable records across Teams, Outlook, and mobile, independent of the flow run's lifecycle.
  • Four approval types govern approver count and response aggregation: First to respond or Everyone must approve/respond, each Approve/Reject or Custom Responses.
  • Listing multiple approvers in one action notifies them in parallel; true sequential approval requires chaining separate approval actions.
  • The Responses array from an approval action holds each individual approver's name, comments, and response date for audit logging.
  • Custom Responses support up to five labeled options, enabling richer branching than simple Approve/Reject via a Switch action.
  • A common escalation pattern pairs 'Start an approval' with a parallel Delay branch that reassigns or reminds if no response arrives in time.
  • 'Start and wait for an approval' is subject to maximum flow run duration limits, so long or uncertain-timeline approvals should avoid the blocking wait pattern.

Practice what you learned

Was this page helpful?

Topics covered

#Programming#PowerAutomateStudyNotes#Approvals#Connector#Sequential#Parallel#Reading#StudyNotes#SkillVeris#ExamPrep