Flow control in nested flows and Composer

A nested (pipeline) flow runs its child steps in order. Flow control lets you change that order at runtime: skip ahead to a later step, jump to a named step computed from a script, or end the rest of the steps entirely. Each control action is guarded by a condition — if the condition is false, the action is skipped and the next step runs as usual.

Flow control works in both the Composer canvas and the classic nested-flow editor. It complements two related capabilities:

• Conditional Execution in Workflows — decides whether a step runs.
• Looping in Workflows — iterates inside a step.

Flow control decides what happens after a step finishes — it's a post-execution gate.

The flow-control actions

Every action except Continue is paired with condition — a JavaScript / Python snippet that returns true or false. If the condition is empty or evaluates to true, the action fires; otherwise the next step runs normally.

Configure flow control in the nested flow editor

1. Open the nested flow.
2. Click a step to open the step inspector on the right.
3. Scroll to After this flow.
4. Pick an action:
   • Continue — no flow control.
   • Go to step — the Go to step dropdown appears with the list of step indices. Pick the target.
   • Dynamic goto — a code editor appears. Set value to the target step name or the keyword END.
   • End — the rest of the steps are skipped.
5. Optionally add a Condition — the action only fires when the condition evaluates true.
6. Save the step.

Configure flow control in Composer

In Composer, the same After this flow options appear in the canvas-side inspector when you select a nested-flow step. The configuration is identical to the classic editor; Composer renders the control as an arrow on the canvas so the routing is visually obvious.

You can drag&drop Control Icon from tools sidebar to the block of nested flow step.

Go to on exception (10.0.8+)

Go to on exception routes a failed step to a recovery step instead of failing the whole nested flow. In After this flow, select Go to on exception and pick the destination in the Go to step dropdown (other enabled steps only; a step cannot target itself). In Composer, the block badge shows "On exception: go to <target>".

The optional Control Condition is evaluated only if the step fails after its retries: leave it blank to log the exception and continue at the selected step, return true to redirect, or false to propagate the failure.

Behavior:

• It runs after the step's retries and existing exception handlers — a failure already swallowed by a child handler does not trigger the jump. Success and conditionally skipped steps continue normally.
• Recovered failures stay visible: the error detail is kept with an ignored-trace status, and failed transformations keep their error metrics. The parent flow succeeds if the recovery path and later steps succeed.
• Cancellation, interruption, and JVM errors are not handled by this action, and it does not undo committed work or external side effects.
• If the condition itself fails, its error is raised and the original failure is kept as a suppressed exception.
• Targets follow reordered steps in the nested flow editor; a deleted or disabled target must be reselected. Composer stores durable target IDs.
• Requires Integration Agent 10.0.1 or newer when the nested flow runs on an Agent.

Branch on a Simba result (10.0.8+)

When the child step is a Run Simba Prompt flow, the Go to step and End nested flow actions offer Use Simba result as condition instead of a condition script: true applies the selected action, false continues to the next step.

• Simba must return a real boolean (true/false) or JSON with a boolean condition field. The string "false", numbers, and prose do not count, and a missing or invalid answer fails the step.
• Requires sequential loop execution (Loop Threads must not exceed 1). In a loop, the last completed iteration decides; a loop with no iterations does not branch.
• It cannot be combined with Dynamic go to step or Go to on exception.
• Downstream scripts can read the result from the variables app_flow_result_<flowId> and app_flow_results (state, auditId, report, error, condition).

Examples

Skip the rest on no records

Step 1 extracts records from a source. If there's nothing to process, skip the remaining load steps:

• Step 1: extract records.
• Step 1 flow control: End with condition etlConfig.getValue('extracted_count') == 0.
• Step 2: load to staging (only runs when there are records).
• Step 3: load to warehouse.

Branch by source type

Different load logic per source type, decided at the end of a setup step:

• Step 1: read source-type from a configuration table.

• Step 1 flow control: Dynamic goto with snippet:

  var sourceType = etlConfig.getValue('source_type');
  if (sourceType == 'salesforce') value = 'Load Salesforce';
  else if (sourceType == 'database') value = 'Load Database';
  else value = 'END';

• Step 2: load Salesforce (named "Load Salesforce").
• Step 3: load Database (named "Load Database").

Retry chain

If a step fails its post-load validation, jump back to the load step:

• Step 1: load data.
• Step 2: validate.
• Step 2 flow control: Go to step 1 with condition etlConfig.getValue('validation_failed') && etlConfig.getValue('retry_count') < 3.
• Step 3: report success.

Notes and limitations

• Self-references are rejected — a step cannot jump to itself directly. Wrap the step in a nested flow if you need a tight loop.
• Forward / backward jumps are both allowed. Use them carefully — backward jumps without a condition create infinite loops.
• Dynamic goto failures (unknown step name, runtime error in the snippet) abort the flow with an error.
• For iterating (process many items), prefer Looping in Workflows. Flow control is for routing, not for iteration.

Related articles

• Composer
• Conditional Execution in Workflows
• Looping in Workflows
• Create a pipeline (nested) flow