Conditions — narrowing when a rule runs
Triggers are coarse: every status change, every record created. Most of the time you only want the rule to fire some of the time. That's what conditions do.
How conditions look
Each condition is one row:
[ field ] [ operator ] [ value ]
Examples:
status equals approved
days greater than 5
priority in [urgent, critical]
reason is not empty
You stack multiple rows; all of them must match for the rule to fire (AND logic).
Operator cheat-sheet
| Operator | Meaning |
|---|---|
| equals | exact match |
| not equals | anything other than |
| greater than / less than | numeric or date comparison |
| in | value is one of a list |
| not in | value is none of a list |
| contains | text contains substring |
| is empty / is not empty | NULL or blank check |
A common pattern — different message per outcome
You'll often want one rule per outcome of the same status field:
Rule 1: trigger record.status_changed
conditions: status equals approved
message: leave-approved-email
Rule 2: trigger record.status_changed
conditions: status equals rejected
message: leave-rejected-email
Rule 3: trigger record.status_changed
conditions: status equals returned-for-info
message: leave-needs-info-email
Three rules, one trigger, three different messages.
Why no OR
OR logic in conditions is hard to read. The platform forces you to write multiple rules — each with one clear set of conditions — instead. This is more rules, but each one is easy to reason about.
Where to next
- Common mistakes.