Advanced run logic and task looping

With the new Run logic panel in the Graphical Designer, you can now define when and how often a task runs using a JSONata expression, replacing conditional wrapper workflows with strategy-driven task-level control.

Getting a task to run only under certain conditions — on a business day, when a file arrives, when an external system reports ready — meant structural workarounds: a dummy predecessor task, an external trigger, or a wrapper workflow that existed purely to gate the run. The Run logic panel removes that overhead. Four strategies, each driven by a JSONata boolean expression, let you configure conditional suppression, wait-until polling, and bounded repetition directly in the task properties of the Graphical Designer, without adding a single extra task to your workflow definition.

Conditions belong in the task, not around it

A task that should run only when a business condition is met now declares it directly: select RUN_IF, write the expression, and the task handles the rest at run time. If the expression evaluates to false, the task moves to SUPPR with sub-status SUPPR_BY_RUN_CONDITION — a state that signals an intentional skip, not a failure, and that satisfies On Success dependencies for every downstream successor. The workflow continues uninterrupted. No wrapper workflow. No dummy predecessor. No manual release.

Wait for the right moment, automatically

REPEAT_UNTIL runs the task once, evaluates the expression after each run, and repeats on a defined interval until the condition becomes true. A task that polls every five minutes for a trigger file declares the expression and the interval. REPEAT_WHILE inverts the logic: repeat as long as a condition holds, stopping when it resolves to false. WHILE_TRUE evaluates before each attempt: if the condition is already false on the first check, the task is suppressed immediately without running at all.

Loops that know when to stop

Set a Maximum repeats cap and the loop exits cleanly when it is reached — no failure raised, no manual cancellation required. A LOOP_STOPPED_BY_MAX_ITERATIONS audit record is written for verification. users migrating pollingCondition definitions benefit from automatic mapping: pollingCondition maps directly to runCondition, and where no strategy is present in the source definition, runStrategy is set to REPEAT_UNTIL to preserve the original polling behavior without manual reconfiguration.

For configuration steps and per-strategy examples, see Configuring run logic for a task. For the full field reference, Orchestration CLI keywords, and migration mappings, see Run logic panel fields.