Control steps

Control steps decide which steps run and how often. Condition, Switch, Loop, Iterator and Try / Catch contain other steps: you add steps to their branches on the canvas, and you can fold them with the chevron on their card.

Condition

Runs steps only when something is true, with an alternative.

Setting	What it does	Required
Condition	A Yes/No expression. Other types are refused: “Condition expression does not yield boolean result”.	Yes

Branches: Then runs when the condition is Yes; Else runs otherwise. After either branch, the flow continues with the step after the Condition. Either branch, or both, can be empty.

Outputs: none.

Example: if GetOrder.totalamount > 10000, then create an approval Task; else approve the order.

Switch

Picks one branch by matching a value.

Setting	What it does	Required
Operand	The value to compare.	Yes
Cases	Added with Add New Switch Case. Each case has an Expression and its own steps.	Yes

Outputs: none.

Behavior: the first case whose value equals the operand runs, and no other case is checked. There is no default case: when nothing matches, no case runs and the flow continues after the Switch. To handle “anything else”, use a Condition instead, or check before the Switch.

Example: switch on Case Priority: High assigns the case to Tier 2, Normal adds it to the support queue, Low sends an acknowledgment email.

Loop

Repeats steps with a counter.

Setting	What it does	Required
Start Index	The first counter value (whole number).	Yes
Count	The last counter value (whole number).	Yes

Outputs (inside the loop): <Step>.Counter (the current value), <Step>.Start and <Step>.Count.

Behavior: the counter runs from Start Index up to and including Count. Count is the last counter value, not the number of repetitions: Start Index 0 and Count 3 runs four times (0, 1, 2, 3). For n repetitions, use Start Index 1 and Count n.

Example: Start Index 1, Count 12: create 12 monthly Payment Schedule rows, with Due Date Add Months(StartDate, PaymentLoop.Counter - 1).

Iterator

Repeats steps for each item in a list.

Setting	What it does	Required
Collection	Any list: a list variable, the result of Execute Query (All), Get Entities By Relationship, Resolve Recipients and so on.	Yes

Outputs (inside the iterator): <Step>.Item, the current item, and <Step>.Index, its position starting at 1. There is no separate item-name setting; the item is always <Step>.Item.

Example: for each Contact of the Account (EachContact over GetContacts Entities), create a Phone Call regarding EachContact.Item.

Break

Leaves the innermost Loop or Iterator it is in. The flow continues with the step after that Loop or Iterator.

Settings: none. Outputs: none.

Behavior: inside a Try / Catch, Break still ends the surrounding loop, after the Finally steps have run.

Example: in an Iterator over an opportunity’s quotes, Break as soon as a quote with status Won is found.

Halt

Ends the whole flow without an error.

Settings: none. Outputs: none.

Behavior:

• Outputs set before Halt are returned.
• Halt is drawn as an end marker. You cannot add steps after it in the same list, and it is not offered by Insert step above.
• Try / Catch does not catch Halt; Finally steps still run.

Example: if the Order was already processed, Set Output AlreadyProcessed = Yes and Halt.

Raise Error

Stops the flow with an error.

Setting	What it does	Required
Error Code	A short code, as plain text, for example CREDIT_EXCEEDED.	Yes
Error Message	An expression for the message the user or caller sees.	No

Outputs: none.

Behavior:

• The flow ends with an application error, and the code and message are returned to whoever started the flow.
• Try / Catch does not catch Raise Error. Finally steps still run.
• When the flow was started by a Run Logic Flow step, the calling flow continues after that step. See Errors in sub-flows.

Example: if the order total exceeds the available credit, raise CREDIT_EXCEEDED with Format("Order exceeds the available credit of {0}", GetAccount.creditlimit).

Try / Catch

Handles errors from the steps inside it.

Settings: none. You add steps to three branches on the canvas: Try, Catch and Finally. Any branch can be empty.

Outputs: <Step>.Error (Text), the error message. Visible only inside Catch.

Behavior:

• If a step in Try fails, the remaining Try steps are skipped and Catch runs. The flow then continues after the Try / Catch step. An empty Catch ignores the error.
• Catch handles errors from any step in Try, including nested steps, called logic blocks and flows, expressions, and REST calls that cannot be sent. A REST call that is sent and fails goes to the step’s Unexpected Error branch instead; see Call Rest Api.
• Finally always runs: after success, after a handled error, and before an unhandled error, Halt or Raise Error ends the flow.
• If a step in Catch fails, Finally still runs and the error then ends the Try / Catch step. An outer Try / Catch can catch it; otherwise the flow fails.
• Not caught: Halt, Raise Error, Break (it ends the loop after Finally), and errors from Dataverse or Dynamics 365 while the flow runs inside the platform’s transaction, for example when a recipe runs it synchronously during a create or update. These end the flow after Finally runs.

The step’s on-screen help reads: “Add steps to the Try branch. If one of them fails, the Catch steps run and can use the error message from this step’s Error variable; the flow then continues. Finally steps always run, even after an error. Halt and Raise Error are not caught, and neither are Dataverse or Dynamics 365 errors while the flow runs inside the platform’s transaction (for example, in a synchronous plugin step).”

Example: in a Try / Catch step named SendWelcome, create and send the welcome email to a new Contact in Try. In Catch, create a “Notification Error” row with the message from SendWelcome.Error. In Finally, update the Contact’s “Last Notification Attempt” date.

Read Error handling for patterns and the full rules.

Related

• Error handling
• Variables
• Logic and control functions