Run SubFlow

The Run SubFlow step calls another flow (a SubFlow) inline. Use it to compose flows out of reusable building blocks – write the logic once, call it from anywhere.

What happens when the step runs

1. Run-SubFlow evaluates each input binding in your calling flow's context (variables, SmartFields, constants).
2. The engine starts the SubFlow version the step is pinned to (see Which SubFlow version runs) inside the same transaction as the calling flow. No commit boundary in between.
3. Steps inside the SubFlow run synchronously. The calling flow waits.
4. When the SubFlow's Return SubFlow Output step fires, its declared outputs become available as variables on this Run-SubFlow step. Outputs declared as Reference (with a Table No.) surface as record references the calling flow can bind into record-scoped SmartFields; outputs declared as Value surface as text-on-the-wire variables.
5. The calling flow continues.

If anything fails inside the SubFlow – a step errors, an Error step fires, the depth limit trips – the whole transaction rolls back and the parent flow sees a single error message prefixed with the SubFlow's name.

Configuration

Field	What it does
Description	Shown on the block in the editor.
SubFlow	Pick which SubFlow to call. Lookup is filtered to flows whose trigger is a SubFlow trigger; non-SubFlow flows aren't selectable.
Version	Read-only, shown as e.g. Version 1.2.0. Set to the SubFlow's active version when you pick it. The calling flow stays on that version even when the SubFlow is published again later.
Switch to version x.y.z	Shown only when the SubFlow has a newer active version than the one the step uses. Click it to move the step to the newer version. Publishing isn't blocked if you don't.
Input Bindings	One row per input parameter the SubFlow declares. Bind each to a value, variable, or SmartField expression. The grid is auto-populated when you pick the SubFlow.

Which SubFlow version runs

The step remembers the SubFlow's version number (see Flow Code and versions). A version number means the same SubFlow version in every company and environment, so the pin travels with the flow when you publish it as a template or export it to a file.

If the remembered version doesn't exist where the flow is installed – for example because the SubFlow there is on a different version – the step uses the SubFlow's active version instead.

Custom icons

Each SubFlow can be configured with a custom icon URL on the SubFlow Card. When set, that icon appears on every Run-SubFlow step that calls it – so a flow editor can recognise "this is the validation SubFlow", "this is the address-cleanup SubFlow" at a glance.

The block's green colour stays the same – the icon override only changes the picture inside the block.

What you can't do inside a SubFlow

• Sleep / time-based deferral. The calling flow is waiting synchronously – pausing would stall it. Use Sleep only in the calling flow, before or after the Run-SubFlow step.
• Add a step after the SubFlow Output. It's a terminating step; the publisher rejects the flow if anything follows.

Errors

If the SubFlow throws (Error step or any other failure), the calling Run-SubFlow step fails with an error of the form:

Error in SubFlow "<name>": <original message>

The transaction rolls back, including any DB writes the SubFlow performed. There's no half-applied state to clean up.