Parametrized workflow with multiple schedules

This blueprint shows how to attach multiple cron schedules to a single parametrized Kestra flow, where each schedule injects its own input values at runtime. Instead of duplicating a workflow once per cron expression, you keep one declarative definition and let several Schedule triggers drive it on independent cadences. This is the foundation for time-based orchestration patterns: hourly versus daily runs, environment-specific parameters, or the same logic exercised with different arguments on different clocks.

How it works

1. The flow declares a single optional input user of type STRING with a prefill of Data Engineer.
2. The hello task (io.kestra.plugin.core.log.Log) logs a greeting that interpolates {{ inputs.user }}, so the message reflects whatever value the run was started with.
3. Two io.kestra.plugin.core.trigger.Schedule triggers are attached. The quarter_hourly trigger uses the cron */15 * * * * and passes only the name input. The every_minute trigger uses */1 * * * * and passes both name and a custom value.
4. Both triggers ship disabled: true so the flow does not start firing the moment you save it. You opt in by flipping disabled to false or removing the property.

What you get

• One workflow definition serving several schedules instead of copy-pasted flows.
• Per-schedule input values, so the same task runs with different arguments on different clocks.
• Safe-by-default triggers that stay dormant until you explicitly enable them.
• A clear template for layering cron cadences onto any parametrized flow.

Who it's for

• Data and platform engineers standardizing recurring jobs.
• Teams that run the same logic across environments or tenants with different parameters.
• Anyone migrating scattered cron entries into one versioned, observable place.

Why orchestrate this with Kestra

A raw crontab can fire a command on a timer, but it cannot pass structured inputs per schedule, retry on failure, backfill missed windows, or show you a searchable history of every execution. With Kestra the schedules live next to the logic they drive in plain YAML, each run is captured with its inputs and outputs for lineage, and you can pair these Schedule triggers with retries and concurrency limits. You also get backfills to replay past intervals on demand, something a bare scheduler simply does not offer.

Prerequisites

• A running Kestra instance.

Secrets

This flow references no secrets.

Quick start

1. Add the flow to your Kestra instance.
2. Run it manually once, optionally overriding the user input, to confirm the log message renders.
3. Enable scheduling by setting disabled: false (or deleting the property) on the triggers you want active.
4. Watch the Executions view to confirm each schedule fires on its own cadence with its own input values.

How to extend

• Replace the Log task with real work (an API call, a query, a transformation) while keeping the multi-schedule pattern.
• Add more Schedule triggers for additional cadences or parameter sets.
• Attach a timezone to a schedule, or add conditions to restrict when it fires.
• Add retries or a concurrency limit so overlapping or failing runs are handled gracefully.

Links

• Core plugin documentation