Parameters, templates and Workflow conditions

Typed parameters, Calculated field templates and Workflow decision conditions are separate mechanisms. A text template is not executable code. A Workflow condition reads only the supported execution context. Preserve these boundaries when moving a value between an editor, Session override and task condition.

Typed parameter definitions

Definitions may declare name, type, description, required, sensitive, overridable, scopes, default, enum, minimum, maximum and maxLength. Up to 100 definitions are supported with unique names. Names begin with a letter, have up to 64 characters and may use letters, numbers, underscores, dots and hyphens. Prefixes sys. and dova. are reserved.

Description is limited to 300 characters. Max length can be 1–32,768, minimum cannot exceed maximum, and enum has 1–50 normalized candidates and is unavailable for JSON/Secret. A sensitive parameter must use Secret; marking an ordinary string sensitive does not turn it into protected custody.

Resolve value layers

The declared precedence is definition default → global → environment → worker → task. A later allowed layer replaces an earlier value. Scopes and Overridable constrain substitutions, and Required checks the resolved value. Inspect provenance in the preview when the value differs from your expectation.

For a laboratory REGION string, use default NORTH, an allowed environment override SOUTH, and an allowed task override CENTRAL. Confirm the task layer wins only when its scope and override rules permit it. Do not remove those restrictions just to make an unauthorized substitution succeed.

Calculated field text templates

${customer} substitutes a field and ${param.region} substitutes a parameter. The result is text, bounded to 4,000 characters. A recognized missing identifier becomes an empty string. A dotted field name is not automatically navigation through a nested object. Use a separate typed conversion when a numeric result is required.

Workflow JSON condition operators

References are limited to parameters.name, variables.name, tasks.id.status and tasks.id.outputs.name. Missing references make ordinary comparisons false. Numbers stay JSON numbers; the condition does not promise automatic conversion from text.

{"all":[
  {"ref":"parameters.RUN_MODE","op":"eq","value":"full"},
  {"ref":"tasks.load.status","op":"eq","value":"succeeded"}
]}

load must be the actual task identifier. Do not assume a universal output field such as row count. Groups all/any contain 1–20 expressions; not negates one expression. Depth over five, trees over 40 nodes and comparison values over 4,096 bytes are rejected.

Test decisions step by step

1. Define RUN_MODE as String with allowed full and sample values.
2. Create a small published laboratory Session and Workflow.
3. Add a Decision with a true expression over parameters.RUN_MODE.
4. Inspect the false branch generated automatically by the UI as the direct negation of the true expression.
5. Publish and run with full, then sample, as two distinct attempts.
6. Verify the selected branch and safe resolved parameters in each attempt.

Workflow task types include Start, Session, Decision, Timer and End; link behavior includes Success, Failure, Always and Expression. Always does not remove all parent/eligibility rules. Inspect references, types and parameter provenance when a decision differs from expectation.