Flow Control, Approvals, and Troubleshooting
Conditions and loops, the four approval types and when each one fits, and how to diagnose a flow that is failing, looping, or silently doing nothing.
Making a flow decide and repeat
A trigger and a straight line of actions handles the simple cases. Real business processes branch, repeat, and wait for people.
Conditions and switches
| Control | Use when | Watch for |
|---|---|---|
| Condition | A binary decision — yes or no branch | Nesting conditions three deep is usually a sign you wanted a switch |
| Switch | One value selects between several known branches | A default case for values you did not anticipate |
| Terminate | Ending the run deliberately with a status you choose | It ends the run — anything after it does not execute |
| Scope | Grouping actions so their combined outcome can be evaluated | This is the building block of the try/catch pattern |
Loops
Two kinds of repeating.
Apply to each is “do this for every item in a list.” You have the list, you work through it, it ends.
Do until is “keep going until something becomes true.” That one needs care, because if the thing never becomes true, you have built a loop with no exit.
The performance trap that shows up in scenarios
An Apply to each containing a data call runs that call once per item. Five hundred items means five hundred calls. This is the single most common reason a flow that “worked in testing” becomes unusably slow in production — the test list had four items.
The better pattern is usually to filter at the source so the loop has less to do, or to use a bulk action where one exists, rather than looping over everything and deciding inside the loop.
Approvals
Approvals are how a flow involves a human decision. The action is Approvals – Start and wait for an approval, and the name is literal: the flow starts the approval and then waits for the response before completing the run.
Approvers can respond from their email inbox, the approvals centre in Power Automate, or the Power Automate app.
The prerequisite people forget
Approvals require a Microsoft Dataverse database. Approval flows are saved in Dataverse.
So “we want approvals but our environment has no Dataverse database” is not a preference problem — it is a blocker. This is a clean exam question because it connects Domain 3 back to the Domain 1 environment decisions.
The four approval types
This is the highest-value table in the module. Each type differs on two axes: whether the options are fixed or maker-defined, and whether one response or all responses completes the request.
| Approval type | Options | Completion behaviour |
|---|---|---|
| Approve/Reject – Everyone must approve | Fixed: Approve or Reject | A response is needed from each approver. Following actions run after all approvers respond, OR when a single rejection occurs |
| Approve/Reject – First to respond | Fixed: Approve or Reject | Approval or rejection by any approver completes the request |
| Custom Responses – Wait for all responses | You define the options | All approvers must respond to complete the process |
| Custom Responses – Wait for one response | You define the options | A response from any approver completes the process |
The detail inside 'Everyone must approve'
Read the behaviour carefully: following actions run after all approvers respond, or when a single rejection occurs.
So a single rejection short-circuits the whole thing. “Everyone must approve” does not mean “wait for everyone regardless” — it means every approver must approve for it to succeed, and one rejection ends it immediately.
That is a genuinely useful distinction, and a natural distractor in a question.
Sequential approval
Beyond the four types, approvals can be sequential: requested one at a time, in a specific order. Each approver must respond before the request moves to the next in the sequence, and the following actions run after all approvers in the sequence have responded.
The discriminator is order. If a scenario says “the depot manager must approve before it goes to finance,” that ordering requirement is what points to sequential — a parallel “everyone must approve” would send both requests at once.
Choosing an approval type
Two questions, and you have the answer
- Are Approve and Reject enough? If the business needs options like “Approve with conditions” or “Send back for revision,” you need Custom Responses.
- Does everyone need to respond, or is one enough? That picks between the “all” and “one/first” variants.
Then check separately whether order matters — if it does, sequential.
Testing and troubleshooting
The objective says “test and troubleshoot cloud flows,” and there is a small toolkit worth knowing by name.
| Tool or technique | Answers | When to use it |
|---|---|---|
| Run history | Did it run? Which step failed? What data went in and out of each action? | Always the first stop — it shows the actual inputs and outputs per step |
| Test pane | Does it work right now, with data I control? | Verifying a change without waiting for a real event |
| Configure run after | What should happen when a step fails? | Building a catch branch instead of letting the run fail silently |
| Scope + run after | Can I group steps and handle their combined failure? | The try/catch pattern |
| Trigger settings review | Why did it not run at all? | When there is NO run history — the flow never triggered |
The diagnostic fork that matters most
Before anything else, ask: is there a run in the history?
- Yes, and it failed → the problem is inside the flow. Open the failed step and read its inputs and outputs.
- Yes, and it succeeded but did nothing useful → a condition evaluated the way you did not expect. The run history shows exactly what the condition compared.
- No run at all → the flow never triggered. Look at trigger configuration — change type, scope, filters — not at the actions.
That fork saves an enormous amount of wasted time, because the third case is invisible if you only look at the flow’s steps.
Kite Freight
Ravi wants overtime requests approved before a run is reassigned. The depot manager decides first; if they approve, finance confirms the cost.
| Requirement | Decision |
|---|---|
| A human decision is needed | Approvals – Start and wait for an approval |
| Environment has a Dataverse database? | Yes — otherwise approvals are not available at all |
| Depot manager decides before finance | Sequential approval — order is the requirement |
| Options beyond Approve and Reject? | Ravi wants “Approve with reduced hours” → Custom Responses |
| Notify the driver of the outcome | A Condition on the response, with different actions per branch |
| Update every run in the affected batch | Apply to each, but filtered at the source first so the loop is short |
A month in, the flow occasionally exits without updating anything. The run history shows the Do until waiting for a confirmation flag exited on its iteration limit rather than its condition — the run succeeded, so nothing looked wrong. Nadia adds an explicit check after the loop, so an exit-by-limit is treated as a failure instead of quietly passing.
Quick recall
Check yourself
An overtime request must be approved by the depot manager first. Only if they approve should it go to finance. Which approval configuration fits?
A flow using 'Approve/Reject – Everyone must approve' has three approvers. The first approver rejects. What happens?
A cloud flow that processes 500 records has become unusably slow. The flow uses an Apply to each containing a data call, then a condition inside the loop to decide whether to act. What is the best improvement?