Designing a Manager Approval Flow in Power Automate
Short answer
ABE Add a Start and wait for an approval action, configure the approvers within it, and branch approved from rejected requests using a condition.
Question
A company uses a cloud flow to manage purchase requests. Each request must be reviewed by a manager before processing. The company requires the following approval functionality: • Requests must be sent to the appropriate manager for approval. • The flow must continue only after a decision is made. • Approved and rejected requests must follow different paths. You need to design the approval flow. Which three actions should you perform? Each correct answer presents part of the solution. NOTE: Each correct selection is worth one point.
Key Takeaways
The question tests the three-part pattern of an approval design — designated approvers, a synchronous waiting action, and outcome branching — and the trap is picking run after settings or secure inputs, which neither pause the flow nor split its paths.
This purchase request approval flow question tests how Power Automate pauses for a manager's decision and then branches on that decision. The correct design combines a Start and wait for an approval action, approvers configured inside that action, and a condition that evaluates the approval outcome.
Common mistake: Option C (run after settings) is the most tempting wrong pick: learners assume the flow must be told how to behave after the approval step, but run after only handles step failure/skip outcomes and does not wait for an approval decision or branch approved versus rejected requests.
Expert Analysis
Why the Answer Is Correct
Option E adds the "Start and wait for an approval" action, which is the only approval action that suspends the flow until a decision is submitted, satisfying the requirement that the flow continue only after a decision is made. Option A configures the approvers inside that approval action, ensuring each request is routed to the appropriate manager rather than a generic recipient. Option B adds a condition that reads the approval outcome (Approved/Rejected responses), which is what drives the two distinct processing paths. Together, A, B, and E cover all three stated requirements: routing, waiting, and branching.Why the Other Options Are Wrong
Option C, run after settings, only control how a flow proceeds when the preceding action fails, times out, or is skipped — they do not block the flow until an approval decision exists, and with a start-and-wait action the flow is already paused at that step. Option D, secure inputs, masks data passed into the action for logging/telemetry privacy and has no bearing on approver routing, waiting for a decision, or branching on the outcome. Neither option contributes to any of the three approval requirements listed in the scenario, so both are excluded from the three required selections.Community Comment Notes
The single community comment selected answer ABE, agreeing that the approver configuration, the outcome condition, and the start-and-wait action form the complete design. The commenter's chosen letters match the analysis above, and no dissenting comments were posted to weigh against that view. As with any vote record, the agreement here is corroboration rather than the basis for the verdict.Official Reference
Exam Strategy
When a question asks for three actions across routing, waiting, and branching, map each requirement to one option and reject any option that only tunes behavior (run after, secure inputs) rather than fulfilling a stated requirement. In Power Automate approval designs, remember that only start-and-wait actions suspend the flow — the plain "Start an approval" action returns immediately.
Frequently Asked Questions
Why don't run after settings let the flow wait for an approval decision?
Run after settings only define behavior when the previous action fails, is skipped, or times out. They do not pause a flow; the start-and-wait approval action is what suspends the flow until a decision is submitted.
Is secure inputs needed on the approval action in this design?
No. Secure inputs only mask data in run history for privacy and have no effect on approver routing, waiting for a decision, or branching on the approval outcome.
Discussion 1 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded.
From public community threads 1
-
exam_upskill 👍 1A. Configure approvers within the approval action. B. Add a condition to evaluate the approval outcome. E. Add a Start and wait for an approval action.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.