Zendesk Trigger Conditions
Triggers fire on ticket create and update. Whether yours behaves depends entirely on the two Zendesk trigger conditions blocks and the order they run in.
The two Zendesk trigger conditions blocks
A Zendesk trigger has a block where every condition must be true, and a block where any one condition being true is enough. Both blocks are evaluated together. If you fill in both, the trigger needs all of the first block to pass and at least one of the second.
That combination is the whole grammar, and it covers more than people expect. "All: ticket is created, form is Billing. Any: priority is urgent, priority is high." Reads awkwardly, works perfectly.
The mistake is putting mutually exclusive conditions in the ALL block. Priority is urgent AND priority is high can never be true simultaneously, so the trigger sits there forever looking correct and doing nothing. If a trigger has never fired once, check this first.
Change conditions versus value conditions
This is the distinction that separates a trigger that works from one that fires eleven times.
A trigger built entirely on value conditions re-fires on every single update where those values still hold, because Zendesk re-evaluates triggers on each update. If you want something to happen once, at the moment of transition, you need a change condition in there.
The classic symptom: a customer gets the same notification four times because the trigger says "status is Pending" instead of "status changed to Pending". One word, four emails, one annoyed customer.
Recipes worth copying
Route by form and skip the rest
All: ticket is created, form is Refunds. Action: set group to Billing, add tag auto_routed_billing. The tag costs nothing and makes the routing auditable later, which you will want the first time somebody asks why a ticket went where it went.
Escalate on a second reopen
All: status changed from Solved to Open, tags contain reopened_once. Action: set priority to High, notify the team lead. Pair it with a simpler trigger that adds reopened_once the first time. Two triggers, and the second reopen is now impossible to miss.
Flag a VIP on arrival
All: ticket is created, organization tags contain vip. Action: set priority, assign to the named group. Do this on the organization rather than per contact, because contacts churn and organizations do not.
Do not notify on a merge closure
Any trigger that emails the requester should carry an ALL condition of tags don't contain closed_by_merge. Zendesk applies that tag when a ticket is merged away, and without the exclusion the customer gets a "your ticket was closed" note about a ticket you deliberately folded into another one.
Order matters more than you think
Triggers run top to bottom in the order they appear in your list, on every create and every update. A trigger that sets a field can therefore change whether a later trigger matches. This is a feature, and it is also the reason your trigger list becomes unmaintainable at around forty entries.
Two habits that help. Put routing triggers before notification triggers, so a notification always reflects the final state rather than the state halfway through processing. And group related triggers together with a naming prefix, because Zendesk sorts by your ordering and your future self will need to find them.
Zendesk also limits how far a chain of triggers firing other triggers can go, to stop infinite loops. If a complex chain stops partway through with no error, suspect that ceiling and check the current docs for the exact figure.
Why your trigger didn't fire
Run this list in order. It resolves most cases in under five minutes.
Then use the ticket events view. Open the ticket, switch the comment feed to show all events, and Zendesk lists which triggers fired and what each one did. It's the single most underused debugging tool in the product.
Frequently asked questions
Why is my Zendesk trigger not firing?
Four usual causes: a change condition that never becomes true, an earlier trigger nullifying it, the trigger being inactive, or the update coming from the same user the condition excludes. A Zendesk trigger not firing is almost never a bug.
What's the difference between ALL and ANY in Zendesk trigger conditions?
Every condition in the ALL block must be true. At least one condition in the ANY block must be true. If you use both blocks, both requirements apply together.
Why does my Zendesk trigger fire repeatedly?
Almost always because the conditions describe a state rather than a transition. Swap "status is Solved" for "status changed to Solved" and it fires once at the moment of change.
Do Zendesk triggers run in order?
Yes, top to bottom on every create and update. An earlier trigger can change a field and affect whether a later one matches, which is useful and also the main source of confusion.
How do I see which triggers fired on a ticket?
Open the ticket and switch the conversation feed to show all events. Each trigger that fired is listed with the actions it performed.
Can a trigger fire on a schedule?
No. Triggers react to a create or update event. Time-based conditions belong in automations, which evaluate on a recurring cycle instead.
Conditions cannot see the other ticket
A trigger evaluates one ticket in isolation, so it can never notice the identical one filed an hour earlier. Ticket Merger can.
Start free trial14-day free trial. No credit card required.