New to Kestra?
Use blueprints to kickstart your first workflows.
Branch Kestra workflows on input values with the Switch task. Run different task sets per case, with a default fallback, all declared in YAML.
id: switch
namespace: company.team
inputs:
- id: string
type: STRING
defaults: B
tasks:
- id: switch
type: io.kestra.plugin.core.flow.Switch
value: "{{ inputs.string }}"
cases:
A:
- id: a
type: io.kestra.plugin.core.debug.Return
format: The input is {{ inputs.string }}
B:
- id: b
type: io.kestra.plugin.core.debug.Return
format: The input is {{ inputs.string }}
defaults:
- id: default
type: io.kestra.plugin.core.debug.Return
format: This is the default case
Build conditional, multi-path workflows in Kestra using the io.kestra.plugin.core.flow.Switch task. This blueprint shows the canonical pattern for routing execution: an input string is evaluated against a set of cases, and a different list of tasks runs for each match, with a default fallback when no case applies. Use it any time a single workflow needs to react differently to events, environments, payload fields, or user choices without splitting logic across several flows.
The flow declares a single input string (default B) and one task, switch, of type io.kestra.plugin.core.flow.Switch. The task evaluates value: "{{ inputs.string }}" and dispatches to one of three branches:
A runs task a (io.kestra.plugin.core.debug.Return) printing the input value.B runs task b (io.kestra.plugin.core.debug.Return) printing the input value.defaults runs task default returning a literal message when the input matches no case.Because Switch is a flowable task, each case can hold a full list of child tasks, not just one, and child tasks execute in order.
if/elif/else style branching in Kestra YAML.cases: keyed by string values plus a defaults: fallback.Switch logic is normally buried inside application code or bash scripts, which makes it invisible to operators. Kestra exposes each branch as a first-class set of tasks with their own logs, retries, and lineage in the Gantt and topology views. Combine Switch with event triggers (webhook, Kafka, Pub/Sub, S3) so that the same flow handles many event shapes, with declarative YAML, per-task retry policies, and replay from any case. No external scheduler offers this level of visibility into conditional branches.
{{ inputs.string }}.This blueprint uses no secrets. Add {{ secret('NAME') }} references inside any case when you extend it to call external systems.
company.team.B and confirm task b runs.A to trigger task a, then with input C to hit the default branch.Return tasks with real work: API calls, SQL, file moves, notifications.dev, staging, prod) and load credentials per case.value from a webhook payload, a previous task output, or a label, not just an input.Switch inside another flowable task (Parallel, ForEach) for multi-dimensional routing.If tasks for boolean checks and Switch for multi-way fan-out.