Skip to main content
How-to guideApplies to: Unified engine deployments
Keep one workflow definition and supply different typed values for each run. Set the initial catalog, namespace, SQL time zone, and name rules once for all tasks.

1. Run a parameterized example

This example uses the same six orders. The default region is North and the minimum amount is zero.
Validate, save as Manual, and start a run. Review the parameter dialog before submitting. Expect: Start a second run with region = South and minimum_amount = 25. Expect Games 30 and Garden 25. Run overrides do not change saved defaults.

Choose types and presence rules

A required parameter needs a supplied value or a default. A nullable parameter permits explicit null. An omitted value and an explicit null are different inputs. An optional parameter without a default must permit its null result. Use enum to restrict accepted values. For a string array, allowed values restrict its elements. Scheduled runs have no prompt, so their required parameters need defaults. Decimals use JSON strings to preserve precision. Integers must fit signed 64-bit values; send values beyond JavaScript’s safe integer range as strings. Decimal precision is at most 38 digits.

Bind values in SQL

Write region = :region, without quotes around the binding. Parameters supply values, not table names, column names, or SQL fragments. Names starting with __ are reserved. A delayed run keeps its logical scheduled timestamp. Use the window bindings to filter the intended period; see Data windows. Incremental workloads have separate parameter restrictions; see Incremental workloads.

Set query context

In workload details, set the shared catalog, namespace, time zone, case sensitivity, and ANSI checks. Apply the same initial settings to every task. Fully qualified table names reduce ambiguity when reading and writing across namespaces. The SQL time zone affects timestamp interpretation. The schedule time zone chooses cron boundaries. They are separate settings. Use UTC for the examples unless a lesson says otherwise. Worker reuse does not make session changes a reliable shared context. Save the intended initial settings on the workload. Use explicit SET or USE tasks for supported session changes within a run and connect their ordering deliberately.

Inspect effective values

Open the run’s recorded invocation to compare supplied values, resolved defaults, revision, and timestamps. The current editor can show a newer revision. Preserve the original submission identity when recovering a lost response; see Definition and API reference.
Last modified on November 4, 2026