Building conditions: all, any, and the trap in between

All and any decide which tickets a rule touches. Two other ideas, is and changed to, decide whether it fires once or every time.

All and any decide which tickets a rule touches. Two other ideas, is and changed to, decide whether it fires once or every time.

All and any

• Meet ALL of the following conditions. Every condition true. This block narrows.
• Meet ANY of the following conditions. At least one true. This block widens.

Alternatives do not belong in the all block. Status is Open and status is Pending, both in all, matches nothing.

The one that catches people

Conditions come in two flavours and they behave completely differently.

• Is. True whenever the ticket is in that state. A trigger with "status is Open" fires on every single update while the ticket is open.
• Changed to. True only on the update where it became that. Fires once.

A notification built on "is" emails the customer on every update for the life of the ticket. Built on "changed to", it emails once, which is what was meant.

The full set is six, not two

For most fields the transition operators come as a set of six. Knowing all of them saves building a tag workaround for something the condition already offers.

Use them whenever the rule is about a transition rather than a state, which is most notification rules.

One edge applies. Changed counts any update to the value, including the first one, so a field going from empty to filled counts as changed. A rule written to catch reassignment also fires the moment a ticket gets its first group, which is at creation.

Two independent sets of alternatives

There is only one any block, so this cannot be expressed directly. The usual answer is a tag: one trigger sets it when the first set matches, and a second reads the tag. Less elegant and far more readable a year later.

See also

• Why my trigger did not fire
• Preventing infinite loops in triggers
• Conditions and actions: the full reference