The order of triggers and why it matters

Triggers run top to bottom on every update, and a later one can undo an earlier one. Order is part of the logic.

Triggers run top to bottom on every update, and a later one can undo an earlier one. Order is part of the logic.

How it runs

All of your active ticket triggers run each time a ticket is created or updated, in the order they are listed. Matching one does not stop the rest.

The part that matters is what Zendesk calls looping behaviour, and it is specific to ticket triggers: actions applied by one can affect how other triggers run and fire. Other types of trigger run simultaneously without it. So a trigger that sets a field or adds a tag can make another trigger true that was not true a moment earlier, which is useful when you rely on it and baffling when you do not.

Two things in that picture decide the outcome. The list is walked again after every update, not once, so a trigger further down can be reached on the second pass because an earlier one changed the ticket. And a trigger that has already fired in this cycle is marked as such and does not fire again, which is what stops the whole thing looping forever.

The two consequences

Later wins

Two triggers setting the same field: the lower one is the result. A rule that seems not to work is often working and then being overwritten four rules further down.

Later can see earlier

A trigger that adds a tag lets a lower trigger condition on that tag. This is the standard way to build something conditional that the two condition blocks cannot express on their own.

An order that stays readable

Notifications above routing is the most common ordering fault, and it produces emails telling the assignee about a ticket that has since gone elsewhere.

There is a ceiling, and it is high

An account can hold a maximum of 7000 active ticket triggers. Nobody reaches that by writing rules one at a time; accounts that come close got there by copying a set per brand or per country. Long before the ceiling, the ordering problem above is what starts costing you, because every one of those triggers runs on every ticket update.

Use categories

Trigger categories group related rules and are ordered as blocks, which makes a large configuration navigable. Without them, a list of eighty triggers is reordered by dragging and nobody can see the shape.

See also

• Organising triggers with categories
• Why my trigger did not fire
• Preventing infinite loops in triggers