# Run another workflow as a step

**Run subworkflow** calls another workflow from a parent workflow. It is useful when several processes need the same enrichment or processing sequence and you want to manage that sequence separately.

## Configure the call

1. Add the Run subworkflow handler.
2. Select the target workflow by its stable identity, or use its name when supported.
3. Decide whether to pass the parent step's incoming records.
4. Connect the parent dependency that supplies those records.
5. Inspect the child workflow's expected inputs and terminal outputs.
6. Run a small example and inspect both executions.

With **Pass inputs** enabled, the parent step's records become the child's trigger input. With it disabled, the child starts with empty trigger input and its sources operate from their own configuration. Passing records does not automatically make every child source read them; use a suitable input-reading source inside the child.

## Understand the returned data

The child creates its own run and job history. The parent step waits for the child outcome and returns the outputs of the child's leaf jobs. When there are several leaves, their outputs are combined in job-ID order. Arrange the child's terminal graph deliberately so the parent receives the intended dataset.

A child failure surfaces as a failure of the calling step, with the child reason available for investigation. Open the child run rather than troubleshooting only the parent's final message.

## Avoid recursive and repeated effects

Do not create a call chain that returns to an ancestor workflow. Recursive ancestry is checked, and child-run capacity is bounded to limit concurrent processing. A child can wait for capacity even when its parent's other branches are active.

A subworkflow is real execution, not an inline preview. Its writes, model calls, and costs occur normally. Retrying a parent call can create another child execution, so child destinations must tolerate intended repetition.

Choose [reusable recipes](/docs/workflows/reusable-recipes) when you need an immutable expanded definition with local bindings. Choose subworkflows when a separately managed callable workflow fits the process. See [reliability](/docs/workflows/reliability) and [outputs](/docs/workflows/outputs).