Control flow: conditions, loops, scope and terminate

What it does

The Control group holds the actions that decide what runs and how often: Condition for two-way branching, Switch for many-way, Apply to each and Do until for iteration, Scope for grouping, and Terminate for ending a run deliberately. Run After sits behind every action and decides which preceding outcomes let it start.

Key facts

A Switch allows 25 cases plus a default. Beyond that you're into nested Switches or a lookup table.
Apply to each processes up to 5,000 array items on a Low performance profile and 100,000 on the others.
Do until has both a count and a timeout. The count defaults to 60 and can be raised to 5,000; the timeout is an ISO 8601 duration that defaults to one hour. The loop exits on whichever comes first — condition true, count reached, or timeout.
A flow definition allows 500 actions and eight levels of nesting. Containers count towards both.
A Scope reports a single aggregate status — Succeeded, Failed, Skipped and so on — which is what makes it useful as the unit for Run After.
Run After accepts any combination of is successful, has failed, is skipped and has timed out. Setting anything other than "is successful" is what stops a failure from ending the run.
Terminate ends the run immediately with a status of Succeeded, Failed or Cancelled, and lets you set an error code and message that show in run history.

When to use / skip

Use Scope liberally — it costs one action and makes both the canvas and the run history readable, and it's the only sane unit for error handling. Use Switch when you're branching on a single value with more than two outcomes, since nested Conditions become unmaintainable fast. Reach for Do until only when you genuinely need polling or retry-until-ready behaviour; if you're using it to iterate an array you want Apply to each, and if you're using it to wait for something you probably want an async pattern instead. Terminate with a Failed status is how you make a business rule violation show up as a failed run rather than a silently successful one.

Configuration decisions

Where scope boundaries fall, because that determines what your error handling can actually catch.
Whether Do until gets an explicit count and timeout, or inherits defaults that will bite on a slow day.
Whether business-rule failures should Terminate as Failed, so they surface in monitoring, or Succeeded with a logged outcome.
Whether logic that has outgrown 500 actions or eight nesting levels moves to child flows now or gets refactored later.
Which Run After combinations each action needs, and whether "has timed out" is handled separately from "has failed".

Gotchas

Run After defaults to "is successful" on every new action. Add a parallel error branch and forget to change it, and the branch never runs.
Actions inside a Scope that fails still show their individual statuses, but the Scope's aggregate status is what Run After reads. People debug the wrong level for hours.
Nesting Apply to each inside Apply to each multiplies request consumption and the inner loop always runs sequentially regardless of concurrency settings.
Do until evaluates its condition after the body runs, so it always executes at least once.
Terminate stops the whole run there and then. Anything you needed to clean up has to happen before it, and a Terminate inside a Scope will not let a following catch Scope run.
The designer silently wraps an action in an Apply to each when you reference a value from an array. That's an extra nesting level against your limit of eight.

Consultant notes

Standardise a scope pattern across the client's flows — a validation scope, a main scope, a catch scope — so any consultant can open any flow and know where to look.
Push back on flows approaching 500 actions. Long before the hard limit they become slow to open and painful to edit, and Microsoft's own guidance is to split them.
Terminate with a clear error code and message is the difference between a support ticket that resolves in ten minutes and one that takes a day. Make it part of the build standard.
Run After configuration is invisible on the canvas. Include it in code review, because nobody spots it by looking at the flow.

Worth another pass if action or nesting limits change, or after any release wave that touches the Control actions.