Skip to content

Conditions

A condition is an expression that decides whether something happens. It is evaluated as true or false, and the answer decides whether a step is shown, which task the case goes to next, or whether a trigger runs.

Where conditions are used

Place Decides Where you write it
Step condition Whether a dynaform, input document or output document appears in the task Task properties → Steps
Trigger condition Whether a trigger attached to a step runs With the trigger, on the step that runs it
Routing rule Which task the case goes to next Gateways and events → Routing rules
Form condition Whether a control is shown or hidden The form's conditional show/hide editor
Inside trigger code Any check you need in the code itself evaluateFunction()

The first three run on the server, in the same engine, and use the expression language described below. Form conditions run in the browser, in JavaScript, and have their own syntax — see Form conditions.

The expression language

A server-side condition is a PHP expression. Anything that PHP evaluates to true lets execution continue; anything that evaluates to false stops it. That includes comparisons, arithmetic, the logical operators and, or, xor and !, and parentheses to group terms.

(@#Amount >= 1000 and @@Priority == "high") or @@Approved == "yes"

Text must be in quotes. A bare word is read as a constant and is almost never what you want.

Reading a variable

Case variables are written with a two-character prefix. The prefix decides how the stored value is read:

Prefix Reads the value as Example
@@ Text @@Priority == "high"
@% Whole number @%Days > 3
@# Decimal number @#Amount >= 1500.75
@? Text prepared for a URL @?Search == "open"
@$ Text escaped for SQL @$Name == "O'Brien"
@= The original value, without conversion @=Count == 0

@? and @$ matter when the value is used to build a link or a query, not when you only compare two values. @= is the safe choice when the variable already holds the type you need, for example a number saved by a grid column.

Choose the prefix when you write the condition

The prefix is part of the expression, not a property of the variable. The same variable can be read as text in one condition and as a number in another.

Comparing a grid

A grid holds rows, not a single value. Read one cell with brackets — the grid, the row, then the column. The first row is 0:

@#Items[0]['Price'] > 100

Form conditions read the same cell with a dot instead of brackets — see Form conditions.

A variable that does not exist

If the condition names a variable that the case has not stored yet, the engine replaces it with an empty string and keeps going. The condition is simply false.

That is convenient while you build a process and dangerous in production: a typo in a variable name does not raise an error, it silently changes the route. When a case takes an unexpected path, check the spelling of every variable in the condition before looking anywhere else.

Routing rules

Routing rules are evaluated in the order shown in the window, and the order is the one you set by dragging the rows.

Gateway When several conditions are true
Exclusive (evaluation routing rule) The first rule in the list wins; the remaining rules are not taken
Parallel by evaluation Every rule whose condition is true is taken
Default flow Used only when no rule matched

If no rule matches and there is no default flow, the case cannot move and stops with Process definition error: All conditions in evaluation routing rule evaluated to false, so workflow has stopped. The fix is in the process definition, not in the case: add a default flow or widen a condition.

See Gateways for the full behaviour of each gateway.

Form conditions

Showing and hiding a control uses a different editor and a different engine: the condition is evaluated in the browser, in JavaScript, and only affects what the user sees. The stored value does not change.

  • Reference a control's value with @#field, and a grid cell with @#grid.column.
  • A rule states what it does — show, hide, show only, hide only, show all, hide all — and which controls it applies to.
  • A rule runs on an event: when the form loads, when a field changes, or both. A text field fires when you leave it, a checkbox when you click it, and a dropdown when you pick another option.
  • The editor can test the condition before you save. Saving an untested condition asks You have not tested the condition. Do you want to save it anyway?; saving one with an error asks You have an error in the condition. Do you want to save it anyway? Both are confirmations, not blocks — read them.

Conditions in trigger code

evaluateFunction() runs an expression from inside a trigger, with a grid as the data source. It is how you apply the same rules to every row of a grid without writing the loop yourself. See Lurana functions.