Parametrized flow with custom validators to ensure correct integer value

Bad input is the quietest cause of broken pipelines: a number out of range, a malformed identifier, a typo in a parameter that only surfaces three tasks later. This flow shows how to catch those problems at the front door using Kestra input validators, so a run either starts with clean, well-formed parameters or never starts at all. It pairs a numeric range check with a regular-expression pattern check, the two most common validation needs in real workflows.

How it works

The flow declares two typed inputs and a single task that consumes them.

• The age input is an INT with prefill: 42, min: 18, and max: 64. Kestra rejects any value outside that inclusive range before execution begins.
• The user input is a STRING with prefill: student and a validator set to the regex ^student(\d+)?$. Only strings that match the pattern are accepted.
• The validator task, of type io.kestra.plugin.core.log.Log, logs the validated values with the message User {{ inputs.user }}, age {{ inputs.age }}.

The regex breaks down as: ^ start of string, student the literal word, (\d+)? an optional group of one or more digits, and $ end of string. So student and student123 match, while studentabc does not.

What you get

• Inputs validated automatically before the first task runs.
• Numeric guardrails through min and max on an INT input.
• Pattern enforcement through a regex validator on a STRING input.
• Sensible defaults via prefill so the form is ready to run.
• A clear log of the accepted values for auditing and debugging.

Who it's for

• Platform engineers standardizing how parameters enter shared workflows.
• Data engineers who want runs to fail fast on bad arguments instead of mid-pipeline.
• Teams building self-service flows where humans supply inputs through the UI.

Why orchestrate this with Kestra

Validation lives in declarative YAML right beside the inputs it guards, so the contract is versioned and reviewable. Kestra checks values at submission time across every trigger path: the UI form, the API, a schedule, or an event. Combined with retries, error handlers, and full execution lineage, you get a workflow that refuses garbage parameters and records exactly what it accepted. A bare script or a scheduler that only fires a command cannot enforce typed, range-bound, pattern-matched inputs before execution, which is the gap this pattern fills.

Prerequisites

• A running Kestra instance.

Secrets

This flow references no secrets.

Quick start

1. Add the flow to a namespace in your Kestra instance.
2. Click Execute and review the prefilled age and user inputs.
3. Submit valid values such as age: 30 and user: student7 to see a successful run.
4. Try age: 70 or user: studentabc to watch validation reject the input.

How to extend

• Add more typed inputs (BOOLEAN, DATE, SELECT, JSON) with their own constraints.
• Tighten or relax the regex to match emails, IDs, or environment names.
• Replace the Log task with real work that depends on the validated parameters.
• Add a schedule or webhook trigger and pass inputs through it.

Links

• Plugin docs: plugin-core