Run flow
Step · Stable
Invoke another workflow as a sub-runnable and surface its RunResult (state / outputs / run_id) in context.
Runs a target workflow synchronously in the same DB connection. input_mapping can pass caller context keys to the child and pre-bind ask_actor answers via _prebind<child_step_label> keys so the child runs unattended. Budget-guarded against infinite recursion via __run_budget in context. Child FAILED halts the parent; child WAITING (un-prebound ask_actor) marks the parent BLOCKED with instructions to pre-bind. Result stored under step label as {state, outputs, run_id}.
When to use
Section titled “When to use”Use when you have a reusable workflow that should be callable as a named sub-routine — e.g. a common “enrich contact + notify manager” sequence invoked from multiple parent flows, or to factor a long flow into readable named stages. The child’s outputs dict is available under the step label so the parent can read them directly.
When not to use
Section titled “When not to use”HARD RULE: never put a human-facing ask_actor inside the CHILD flow expecting it to pause and wait for a person — the runner cannot resume a nested WAITING state, so an un-prebound ask_actor in a child marks the WHOLE parent run BLOCKED (a failure), not paused. Sub-flows must be pure/deterministic: extraction, lookups, transforms, sends. Keep every approval / “who handles this?” / manual-review ask_actor in the TOP-LEVEL flow that owns the trigger, never inside a Run flow target. If you need LLM-driven tool-calling rather than a deterministic sequence, use Run agent instead. If the logic is simple enough to inline (a few steps), just add the steps directly — sub-flows add indirection cost that is only worth it for genuinely shared or complex sequences.
Inputs
Section titled “Inputs”string · required
Which saved workflow to run as a sub-routine. Accepts either the flow’s display name or its workflow_id (id is more stable across renames). The child runs synchronously, in the same DB connection.
Example: enrich-contact-and-notify
- ✓
enrich-contact-and-notify— a reusable sub-flow name shared across several parent flows - ✗
{{ trigger.flow_name }}— the target must be a known flow at save time for the integrity checks — do not template this from run data
input_mapping
Section titled “input_mapping”dict · optional
A dict merged into the child’s run context. Any _prebind<child_step_label> key pre-answers that ask_actor step in the child so it never enters WAITING — required because a nested un-prebound ask_actor marks the whole parent run BLOCKED.
Example: {"contact_email": "{{ trigger.from_email }}", "__prebind_review": "approve"}
- ✓
{"contact_email": "{{ trigger.from_email }}"}— passes the parent’s trigger value straight through - ✓
{"__prebind_review": "approve"}— pre-answers the child’s “review” ask_actor step so it runs unattended - ✗
{"contact_email": trigger.from_email}— not valid JSON/Jinja — template refs need the {{ }} delimiters: ”{{ trigger.from_email }}“
Outputs
Section titled “Outputs”Auto-generated from the skill registry (load_skills()). Do not edit by hand.