Job Variables

Job variables use custom definitions from the shared variable catalog. They let a saved job override an inherited value and optionally ask for a run-specific value when a person starts the job. Tasks read the result through vars.*.

See Variables for the complete scope table, folder behavior, group conflicts, and product/package rules.

Configure infrastructure folder values

Open an infrastructure job folder and select Variables. Use Actions > Add override to set a custom variable for every infrastructure job in that folder or its descendants. New variable is available to super administrators who need to add a definition to the shared catalog.

Resolution runs from the definition default through the infrastructure folder ancestry and finally the job override. The most specific applicable value wins. The table shows the full source folder path and marks it as the current or an ancestor folder.

Only infrastructure job folders supply inherited job values. Endpoint-job folders organize jobs but do not add an endpoint variable layer.

Configure a job

Open a saved job and select Variables. Use Actions > Add override to choose another custom definition, or select Configure on an existing row. The configuration panel provides two independent settings:

• Override inherited value enables or removes the persistent value on this job.
• Prompt offers the person starting the job an optional run-specific override.

A prompted variable starts in Default mode and uses its persistent effective value unless the person starting the job selects another mode. If no definition default, inherited value, or job override applies, the value resolves to null.

Non-secret string prompts can define a fixed list of label/value choices. Submitted non-null values must match one of the configured values. An explicit null remains available when a choice list is configured. Secret prompts always use password fields and cannot store fixed choices. Prompt order controls the field order in launch and self-service forms.

Secret definitions are supported. Prompted secret values use password fields and are encrypted in the run snapshot. Select Default to omit a run override and use the effective value resolved when the job runs.

Choose a table view

Use the View selector to control which definitions are listed:

• Configured shows direct job overrides and variables with Prompt enabled.
• Effective also shows inherited values, definition defaults, and unresolved group conflicts.
• All variables shows every custom definition available to jobs, including definitions with no value or job settings.

The source column identifies the exact definition, folder, tenant, group, endpoint, product, package, or job that supplies the displayed value.

For endpoint jobs, the value column is labeled Job default. It combines the definition default and any direct job override. Tenant, endpoint folder, matching group, endpoint, product, and package values are resolved for each target and task when the job runs, so those values are not included in the saved job default. A job override applies to every target and task in the run.

Start a job

Interactive launch actions display all prompt-enabled variables before confirmation. Each prompt provides the applicable value modes:

• Default submits no run override and uses the effective value resolved when the job runs. If no value is configured, the job receives null.
• Custom value submits the entered launch-specific value. Text input is trimmed, and the value must not be blank.
• No value deliberately submits null for a non-secret variable.
• Empty text deliberately submits an empty string for a non-secret free-text string variable.

Boolean and fixed-choice prompts combine Default, their available values, and No value in one selector. A fixed choice whose configured value is an empty string keeps its own label and submits empty text, distinct from both Default and No value. Secret prompts provide Default and Custom value with a masked input. Explicit false, zero, JSON values, null, and empty strings remain distinct from the omitted Default mode. Ordyn validates types, fixed choices, and prompt eligibility when it creates the run.

A job-level or submitted value applies to every target and task in an endpoint run. Without either value, the effective persistent value can vary by endpoint, product, and package. An unresolved value is available as null so the job can decide whether to skip work, use another path, or fail through its own task logic.

Schedules, webhooks, automations, assignments, and composed child jobs do not submit prompt values. They resolve persistent values only and proceed when a value is unresolved. Child jobs resolve their own variable configuration and do not receive mappings from the parent job.

Run snapshots

Infrastructure runs freeze the effective definition-default, folder, job, and submitted values when the run is created. Changing those persistent values later does not alter the active run.

Endpoint runs freeze the job-level and submitted overlay. Tenant, endpoint-folder, group, endpoint, product, and package values continue to resolve in their existing target context. This keeps endpoint-specific values live while making the job/run overlay reproducible.

The run context shows the frozen values, their source, and whether a value was submitted. Secret values are masked.

Copy, templates, and bundles

Prompt, order, and choice settings are structural job behavior. Copying a job or creating a template from it retains those settings, and complete-job export/import carries the referenced variable definitions with them. Persistent folder and job override values and all run values are deliberately excluded; configure values for the copied or imported job after saving it.

Use values in tasks

Reference effective persistent values through vars.<key> in supported templates and expressions:

{{ vars.release.channel }}

This is the same reference whether the value came from the definition default, an inherited scope, the job, or the run prompt.

Use an explicit condition when behavior depends on whether a value is available:

vars.release.channel == null
vars.release.channel != null
is_empty(vars.release.channel)

Use is_empty(...) when null and an empty string should be treated alike. Use an explicit null comparison when false, zero, or an empty string must remain valid values.

job.vars.* remains a separate space populated by Set job variable. Those values are local and are not persistent variable definitions.