Input binding and screen chaining

Most properties in a screen definition can be bound to an input instead of being written as a literal, using the {{name}} syntax. This is how you chain screens together. Values collected (or computed) earlier in the start dialog become inputs to a later screen, letting you build labels, defaults, option lists, and even show/hide logic dynamically.

The binding syntax

An input reference is written as {{name}}, where the name consists of letters, digits, and underscores. Every distinct name used in a screen automatically becomes an input parameter of that screen . The editor lists them on the Parameters tab, and using the same input name with two different types (for example once as a boolean and once as a string) is rejected when saving.

How a binding resolves depends on the property's type:

• String properties (label, title, description, helpText, string value, regex, systemSubType, option labels/values) support interpolation: the binding can be embedded in text and several bindings can be mixed in one string.

  "label": "Restart {{systemName}} ({{environment}})?"

  If an input has no value at runtime, the placeholder is left as-is in the text.

• Non-string properties (required, available, optional, multiSelect, allowPast, minValue, maxLength, step, numeric/boolean/list values, options, table values, systemType, fileBundleType) must be bound as the entire value — exactly "{{name}}", nothing around it:

  "available": "{{isProduction}}",
  "maxValue": "{{maxJobs}}"

  The input's value is converted to the property's type (boolean, integer, float). If the input is missing or not convertible, the property falls back to its default (usually null).

• List-valued properties (select/text-list/system value, select options, table values) accept an input containing a JSON array string. A plain single value is also accepted for select and text-list values and is treated as a one-element list.

Where input values come from

A screen used in a start dialog is a step like any other, its inputs are wired in the workflow editor, typically to the outputs of earlier screens or script steps in the same start dialog, or to constants. The bindings are resolved just before the screen is shown, using the values available at that point.

When a screen field's value flows onward as an input, it is converted to a string:

• Boolean, integer, float, datetime, text, files: the plain value.
• Single-select and single-system fields: the selected option value / system ID.
• Multi-select, multi-system, and text-list fields: a JSON array.
• A table produces one output (named after the table's id) containing all of its rows.

Dynamic select options

A Select field's options property can be bound to one of three built-in option providers instead of a screen input. The options are looked up when the screen is shown, filtered to the customer selected on the first screen and to what the current user is allowed to see:

Binding	Options offered
"options": "{{credentials}}"	Shared credentials visible to the user, plus credential purposes (sorted by name; value is the credential/purpose ID)
"options": "{{customChecks}}"	Custom checks visible to the user (value is the check ID)
"options": "{{allSystems}}"	All monitored systems visible to the user (value is the system ID)

Alternatively, options can be bound to a regular input holding a JSON array of {label, value} objects. For example, produced by a script step earlier in the start dialog.

Showing and hiding fields dynamically

Binding available on a field or section to a boolean input is the standard way to build conditional forms. A checkbox on screen 1 can control whether a whole section appears on screen 2. Two behaviors to be aware of:

• A field that is unavailable (or in an unavailable section) is never validated as required.
• When a screen is submitted, an unavailable field's configured default value is still emitted as its output (or the output is omitted entirely if it has no default). Hidden fields therefore produce predictable values downstream.