Conditions
How Branch and loop conditions are built from rules, the tests each field type can answer, and when to reach for an expression instead.
A Branch step decides which path a run takes. Do While and Do Until loops decide whether to go round again. Both ask the same kind of question, and both are built the same way: as rules you assemble from dropdowns.
A rule is a field, a test, and a value
Each rule reads one piece of data, applies one test, and compares it against one value:
Score the enquiry · Fit score is at least 7
Read the enquiry · Subject contains invoice
Classify the email · Is a lead is true- The field comes from the same picker the
{{...}}fields use — every step upstream of this one, plus whatever the trigger publishes. Nothing is addressable in a condition that isn't addressable elsewhere. - The test is filtered to what that field's type can answer. A yes/no field offers is true and is false; a number offers the ordering tests; text offers contains and starts with. You can't build a rule that asks a question its field can't answer.
- The value control matches the field's type too — a toggle for a yes/no field, a number input for a number, a date picker for a date.
To compare one field against another rather than against a fixed value, select Compare with another field beside the value and pick the second field.
All rules, or any rule
With two or more rules, a small and / or chip sits between them. Select it to switch the whole group between every rule must pass and any rule passing is enough. There's one setting for the group, not one per pair.
The tests
| Test | Available on | Passes when |
|---|---|---|
| is | every type | the two values match |
| is not | every type | the two values don't match |
| is true | yes/no | the value is true |
| is false | yes/no | the value is false |
| is empty | text, lists | there's no value, or only whitespace |
| is not empty | text, lists | there's a value with something in it |
| contains | text, lists | the text contains what you typed, or the list holds it |
| does not contain | text, lists | it doesn't |
| starts with | text | the value begins with what you typed |
| is more than | numbers, dates | the value is greater |
| is at least | numbers, dates | greater or equal |
| is less than | numbers, dates | the value is smaller |
| is at most | numbers, dates | smaller or equal |
Text comparisons ignore case: contains, does not contain and starts with
match "Invoice" against invoice.
Empty means empty
is empty treats a field holding only spaces as empty, which is almost always what you meant — use it rather than comparing against an empty value.
Where the type isn't known
Cheqq works out a field's type from the step or trigger that produces it. Where it can't — a step returning free-form JSON, for instance — every test is offered rather than a guessed subset, so nothing is hidden from you. Pick one that suits the data you expect.
The verdict
Underneath the rules, a line says what this condition would decide with the data you have right now, drawn from the most recent output of the steps it reads:
With the data you have, this is true
Each rule shows the value it actually read, so a condition that isn't behaving tells you which half is wrong. A rule reading from a step that hasn't produced anything yet reads no sample yet rather than counting as a failure — run Test Step on the steps it reads, and the verdict fills in.
When rules aren't enough
Some questions don't decompose into field-test-value — arithmetic across two
fields, or a check on the shape of a list. Select Write an expression and
the rules are replaced by a JavaScript boolean expression evaluated in a
sandbox. Inside one, inputData and steps are available directly, with no
braces, and loops additionally expose iteration, the current 0-indexed count:
steps.classifyEmail.category === "urgent"
inputData.amount * inputData.quantity > 1000
iteration < 5The sandbox has no access to Node globals, process.env, or require — only
the data explicitly passed into it.
Expressions are a variant of the same field, not a different one, so switching is not a one-way door. If an expression can be expressed as rules, Build this with rules instead converts it back.
Rules are the faster path
A condition built from rules is evaluated directly. An expression is evaluated in a sandbox, which costs a little more per run. On a branch that runs on every record change, that difference is worth having.
Loops need one
A Do While or Do Until loop needs a condition to know when to stop. Leave one empty and the workflow refuses to run, naming the loop — rather than going round an unpredictable number of times.
Continue with Error handling for how
failures inside these steps are handled, or Expressions
for the {{...}} syntax used everywhere else.