v2.1.6+Run logic

The Run logic panel is a unified configuration area in the Graphical Designer that consolidates data iteration, conditional suppression, and looping strategies into a single task level control, enabling you to define when and how often a task runs without building workaround pipelines.

The Run logic panel absorbs the Repeat for each value field from Scheduling options and introduces four run strategies driven by JSONata boolean expressions. These controls let you express iteration, suppression, and polling behavior directly in the task definition without building conditional wrapper workflows.

Run strategies

The Run strategy field controls when the run condition is evaluated and what happens when it resolves to false.


Strategy	Evaluation point	Run condition	Loop exit	Final state on exit
`RUN_IF`	Pre-run	Expression must be `true` to run.	N/A — single check	True: task runs. False: `SUPPR` with sub-status `SUPPR_BY_RUN_CONDITION`.
`WHILE_TRUE`	Pre-run	Expression must be `true` to run.	Expression evaluates to `false`.	First check false: `SUPPR`. Subsequent loop exit: terminal run is `SUPPR`. Lifecycle status reflects the previous successful run.
`REPEAT_WHILE`	Post-run	Always runs at least once.	Expression evaluates to `false`.	Reflects the status of the final run.
`REPEAT_UNTIL`	Post-run	Always runs at least once.	Expression evaluates to `true`.	Reflects the status of the final run.

The run condition expression must return a strict boolean. If the expression returns any other type — string, number, null, or object — the task transitions immediately to FAIL with error code FAILED_PRECONDITION and the parent workflow abends.

Task lifecycle and pipeline impact

When a task is skipped by a RUN_IF or WHILE_TRUE evaluation, it moves to a clean SUPPR state with sub-status SUPPR_BY_RUN_CONDITION. This distinguishes intentional skips from run failures and prevents ambiguous monitoring states.

A task in SUPPR state satisfies On Success dependencies for downstream successor tasks. The workflow continues without breaking the downstream pipeline sequence.

When a loop exits because it reaches the configured Maximum repeats cap, the run stops cleanly without raising a failure. HCL Universal Orchestrator logs an internal audit record LOOP_STOPPED_BY_MAX_ITERATIONS for verification.

Within any run condition expression, you can reference the current iteration number using the 1-based tracker variable accessed as $this().iteration.