Zendesk Trigger vs Automation
Zendesk trigger vs automation comes down to one fact: both change tickets without an agent, and only one of them can react to time passing.
Zendesk trigger vs automation: event-driven or time-driven
A trigger is event-driven. It evaluates the moment a ticket is created or updated, and only at that moment. No event, no evaluation. A ticket can sit untouched for a fortnight and every trigger in your account will ignore it completely, because nothing happened.
An automation is time-driven. It runs on a schedule against the whole eligible queue, looking for tickets that have been in some state for long enough. Zendesk documents this as roughly hourly, so treat it as "within the hour" rather than "at 09:00". Anything that needs to happen at a precise second is not an automation.
That is the whole distinction. Everything else follows from it. If you catch yourself asking "but which one is better", you have asked the wrong question, because they do not overlap as much as the names suggest.
When each one actually fires
The detail matters more than the headline, and this is where most confusion lives.
Two worked examples of picking wrong
The chaser that never chases
You want to nudge a customer who has not replied for three days. Somebody builds it as a trigger with the condition "hours since update is greater than 72". It never fires, and the admin spends an afternoon convinced Zendesk is broken.
It isn't broken. A trigger only evaluates when the ticket is updated, and the entire point of this rule is that the ticket is not being updated. The rule is asking to be run on silence, and silence isn't an event. Rebuild it as an automation and it works first time.
The escalation that arrives an hour late
The opposite mistake. A VIP customer replies and you want the ticket reassigned to the senior queue immediately. Somebody builds it as an automation, because escalation felt like something that runs on a timer.
It works, technically. It also runs up to an hour after the reply landed, which on a one-hour first response target is the entire budget spent on waiting for a scheduler. The customer replying is an event. Events want triggers.
The general shape of the error is the same in both directions: people categorise by what the rule does rather than by what makes it run.
The test that settles it
Finish this sentence about your rule: "this should happen because ___".
If the blank is filled by something a person or a system did, build a trigger. Ticket created, comment added, status changed, field set, form submitted. All events.
If the blank is filled by something that did not happen, build an automation. Nobody replied. Nobody picked it up. It has been pending too long. All absences.
And there is a third answer nobody likes: some things are neither. Both engines evaluate one ticket at a time, in isolation, with no visibility of any other ticket. A rule cannot ask "is there another open ticket from this person about this". That question is outside what either engine can express, which is why comparison logic lives in apps and the API instead of in the rules.
Three habits that keep both tidy
Name rules so the ordering makes sense. Prefixing with a number or a category means the list reads as a sequence rather than as a pile. Future you will be grateful.
Give every automation a stop condition before you give it an action. Write the "and tag is not X" line first. It costs five seconds and it is the difference between a chaser and an hourly spam cannon aimed at your own customers.
Check both engines when something misbehaves. Plenty of "the trigger is wrong" tickets turn out to be an automation quietly setting the field back an hour later. If a value keeps reverting on a schedule, you are looking at the wrong list.
For the wider setup, the triggers versus automations overview covers the concept, and trigger conditions goes into how the ALL and ANY blocks combine.
Frequently asked questions
When should you use an automation rather than a trigger?
When nothing has happened. The difference between a Zendesk trigger and an automation is the event: triggers need a change, automations need time to pass. When to use Zendesk automation comes down to whether your condition is about waiting.
Can a Zendesk automation run instantly?
No. Automations run on Zendesk's schedule, documented as roughly hourly, so the earliest realistic response is "within the hour". Anything needing an immediate reaction has to be a trigger.
Why is my trigger not firing on an old ticket?
Because nothing updated the ticket. Triggers only evaluate on create and update events. A condition about elapsed time in a trigger will only ever be checked when somebody touches the ticket anyway.
Zendesk trigger vs automation: can they do the same job?
Occasionally, for something like tagging, where timing does not matter. Usually not. Pick based on what makes the rule run rather than on what the rule does.
Do automations count as updates for triggers?
An automation changing a ticket is an update, so triggers can see it. That's worth remembering before you build a rule whose actions feed straight back into another rule.
How many triggers is too many?
There is no hard number worth quoting, but once nobody on the team can predict the outcome of a new ticket, you have too many. Audit the list yearly and deactivate rather than delete first.
The rule neither engine can write
Spotting that two tickets are the same request needs a view of the whole queue. That is the gap Ticket Merger fills.
Start free trial14-day free trial. No credit card required.