Trigger a sub Flow

Trigger a Kestra subflow from a parent flow to compose larger pipelines out of small, reusable units. This blueprint shows the parent-child execution pattern: the parent computes a value, then calls a child flow by flowId and namespace, passing typed inputs and consuming the child's outputs downstream. It is the foundation for modular orchestration, shared utilities, fan-out patterns, and clean separation between business logic and infrastructure tasks.

How it works

1. The parent flow runs task_a, an io.kestra.plugin.core.debug.Return task that produces a value ("task_a - flow_a") and exposes it as outputs.task_a.value.
2. The parent then runs flow_b, an io.kestra.plugin.core.flow.Subflow task that calls the child flow my_subflow in the same namespace via "{{ flow.namespace }}".
3. The subflow is invoked with inputs.my_input bound to "{{ outputs.task_a.value }}", so the child sees the parent's output as a typed input.
4. The child flow executes its own tasks and returns control to the parent, which can read the subflow's outputs and continue.

What you get

• A working parent-child pattern using io.kestra.plugin.core.flow.Subflow.
• Typed input passing from parent outputs into child inputs.
• Namespace-relative subflow calls via "{{ flow.namespace }}" so the pair stays portable.
• A clean starting point for libraries of reusable flows.

Who it's for

• Platform engineers building shared orchestration libraries across teams.
• Data engineers factoring large DAGs into smaller, testable units.
• SREs standardizing incident, deploy, and cleanup routines as callable subflows.

Why orchestrate this with Kestra

Subflows in Kestra are first-class executions: each child run has its own ID, logs, retries, labels, and lineage, and is visible in the UI as a separate execution linked to its parent. You get declarative YAML, event and schedule triggers on either flow, per-task retries, and full observability across the parent-child boundary, something ad hoc function calls or inlined scripts cannot give you. It also lets independent teams own and version their subflows separately while still being callable from any parent pipeline.

Prerequisites

• A running Kestra instance (OSS or Enterprise).
• Permission to create flows in the target namespace.

Secrets

This blueprint does not reference any secrets. Add {{ secret('NAME') }} references if you extend the subflow to call external systems.

Quick start

1. Create the child flow my_subflow in the same namespace (for example company.team) with a STRING input my_input and any tasks you want to reuse.
2. Save this parent flow as trigger-subflow.
3. Execute the parent from the UI or API.
4. Open the parent execution and click into the linked child execution to inspect inputs, outputs, and logs.

Example child flow:

id: my_subflow
namespace: company.team

inputs:
  - id: my_input
    type: STRING

tasks:
  - id: task_b
    type: io.kestra.plugin.core.debug.Return
    format: "{{ task.id }} - subflow - {{ inputs.my_input }}"

How to extend

• Add outputs to the subflow and consume them in the parent via outputs.flow_b.outputs.<name>.
• Set wait: false on the Subflow task to fire-and-forget the child.
• Use ForEach in the parent to fan out the subflow over a list of inputs in parallel.
• Move the child into a different namespace and call it cross-team by setting namespace explicitly.
• Add labels to the subflow call to tag child executions by tenant, environment, or run type.

Links

• Plugin docs: https://kestra.io/plugins/core