Plan requirement
| Subscription | Any plan |
| Access | Admin |
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
On each update Zendesk works down the list. Every trigger whose conditions match runs, in order. They all get their turn; matching one does not stop the rest.
Because they run in sequence, a trigger halfway down sees the changes made by the ones above it. That is useful when you rely on it and baffling when you do not.
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
- Categorise and tag first. Rules that work out what a ticket is.
- Route next. Group, assignee, skills, queue.
- Notify last. So messages reflect where the ticket ended up rather than where it started.
Notifications above routing is the most common ordering fault, and it produces emails telling the assignee about a ticket that has since gone elsewhere.
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.
Comments
0 comments
Article is closed for comments.