Understand control flow steps

Wait step

A wait step pauses the workflow run for a configured duration. When execution reaches a wait step, the workflow pauses for the specified time, then continues to the next connected step. The canvas displays a live countdown timer during the pause.

You can configure the duration in days, hours, minutes, and seconds. A platform administrator can set a global maximum wait duration to prevent workflows from holding resources indefinitely. The default maximum is 30 days.

Use wait steps to:

• Delay between API calls to avoid rate limiting
• Wait for an external system to finish processing
• Add a cooling-off period before retrying a failed operation

Switch step

A switch step evaluates conditions and routes execution to the first matching branch. Unlike a conditional step that provides binary true/false routing, a switch step supports multiple output paths. The switch uses first-match-wins evaluation: the switch checks paths in definition order, and execution follows the first path whose expression is true.

Each path has a name and a path expression. You can build path expressions in two modes:

• Visual expression builder: Build conditions using a structured form. Each condition evaluates a field from an upstream step output against a value using a comparison operator. Combine multiple conditions within a group using AND or OR logic. Nest groups to create complex multi-layered expressions, such as (Condition A AND Condition B) OR (Condition C). Select the Not checkbox on a condition or group to invert its logic.
• Custom expression: Enter a raw expression string directly for advanced use cases.

A fallback path handles situations where no path expression matches. You can configure up to 100 paths per switch step. You can reorder paths by dragging the grip handle on each path to change the evaluation priority.

Use switch steps to:

• Route remediation actions based on severity (critical, warning, informational)
• Select environment-specific steps (dev, staging, prod)
• Branch on task agent output category

Conditional step

A conditional step evaluates a single expression and routes execution to one of two paths: true or false. Use a conditional step when you need binary branching based on one decision point. For more complex routing with multiple named paths, use a switch step instead.

The conditional step uses the same expression builder as the switch step:

• Visual expression builder: Build conditions using a structured form with Field, Operator, and Value inputs. Combine conditions with AND or OR logic, and nest groups for complex expressions.
• Custom expression: Enter a raw expression string directly, for example ${status} == "completed".

Available comparison operators include equality, greater than, less than, contains, starts with, ends with, matches regex, exists, and is empty. Select the Not checkbox on a condition or group to invert its logic.

If you leave the false output unconnected, the workflow branch ends when the condition evaluates to false.

Use conditional steps to:

• Check whether a previous step succeeded or failed before continuing
• Evaluate a threshold value and branch on the result
• Gate a destructive action on a safety check

Converge step

A converge step waits for steps that run in parallel to finish before continuing. Use this step when multiple branches run at the same time and the workflow should wait before continuing. For example, after fanning out from one step into tasks that execute in parallel. When multiple parallel branches connect to a single downstream step, you must use a converge step. Joining branches without a converge step results in undefined execution order.

The converge step supports two join strategies:

• All branches reach this step: Wait for every predecessor branch to complete before continuing. Use this strategy when the next step requires results from all branches.
• Any branches reach this step: Wait for a specified number of branches to complete, then continue without waiting for the remaining branches. Use this strategy when only a subset of results is needed.

You can configure an optional wait duration on the converge step to prevent it from waiting indefinitely. The timeout clock starts when the first step in the parallel section is scheduled, not when a direct predecessor completes. When the wait duration expires, the converge step fails. To control what happens after a failure or timeout, select an option from the On failure behavior list on the Settings tab. Continue on failure allows downstream steps to proceed with whichever branches have completed. Stop workflow or branch on failure halts execution.

When a converge step completes or times out, the system detaches any steps still running in the parallel section and cancels them. Steps on incomplete branches that had not yet started are marked as skipped.

The canvas displays the active strategy label (All or Any N) on the converge step.

Use converge steps to:

• Collect results from parallel remediation tasks before sending a summary notification
• Wait for concurrent validation checks before deployment
• Synchronize data-gathering branches before a task agent analyzes combined output
• Proceed after the fastest N branches complete, without waiting for slower paths

When you do not need a converge step

You do not need a converge step after conditional, switch, or approval steps. Those steps route execution to one branch only, so there are no concurrent paths to synchronize.

Exclusive branching (no converge step needed):

Conditional, switch, and approval steps evaluate a condition and route execution to one branch. The other branches do not execute. Connect each branch directly to the next step. In the execution detail view, the canvas highlights the taken path with a green border and checkmark on the branch handle. Skipped paths display as dashed edges, and skipped downstream steps appear with dashed borders at reduced opacity.

Parallel branching (converge step required):

When you connect one step's output to multiple downstream steps, all connected steps start at the same time. Use a converge step to synchronize these parallel branches before continuing to a shared downstream step.

How the converge step handles failures

• When a predecessor step fails, the converge step evaluates whether the join strategy can still be satisfied. If not, the converge step fails.
• To allow downstream steps to continue after a converge failure, select Continue on failure from the On failure behavior list on the Settings tab.
• Steps that were running in the parallel section are cancelled. Steps that had not yet started are skipped.

Loop step

A loop step repeats a set of steps within a workflow. When execution reaches a loop step, the system runs the steps inside the loop body repeatedly. After each iteration, the loop evaluates whether to continue or stop. When the loop completes, the workflow continues on the done path.

Two loop types are available:

• For each: Iterates once for every item in a collection. Use this type when you have a known list of items to process, such as servers, users, or incidents from an earlier step. During each iteration, the loop provides ${loop.item} (the current item) and ${loop.index} (the zero-based index).
• While: Repeats the loop body as long as a conditional expression evaluates to true. Use this type when you are waiting for an external change or a specific state. For example, you can poll an API endpoint for a status update. The first iteration always executes regardless of the condition.

You can set a maximum iteration limit to prevent infinite loops. If the loop reaches this limit, the On failure behavior setting controls what happens next.

During execution, the loop step displays an iteration count badge on the Loop branch handle. The badge shows the current iteration number while the loop is running and the total iteration count when the loop completes. The execution detail activity table displays a separate row for each iteration of the loop body. You can inspect the result of individual iterations.

Use loop steps to:

• Process a list of items in batch, such as patching servers or provisioning user accounts
• Poll for a state change, such as waiting for a deployment to finish
• Retry an action until it succeeds or reaches a maximum attempt count

Sequential and parallel execution

Sequential execution is the default behavior. When you connect one step's output to another step's input, the workflow engine runs them in order. The second step waits for the first step to complete before it starts.

You can run multiple steps at the same time by connecting one step's output to more than one downstream step. When the upstream step completes, all connected downstream steps start concurrently. No dedicated parallel step is required — parallelism is implicit in how you connect the steps.

After parallel branches complete their work, use a converge step to rejoin them into a single execution path.

Combine control flow steps

Control flow steps work together to build complex execution patterns:

• Use a switch or conditional step to route execution along one of several exclusive branches. Each branch can reconnect to a shared downstream step without a converge step.
• Add wait steps within a branch to pace execution before convergence.
• Follow a converge step with a switch step to route consolidated results.
• Place a loop step inside a branch to iterate over items before the branch converges.
• Nest a conditional step inside a loop body to skip items that do not meet criteria.