The difference in one line: triggers fire when something happens; automations fire when time passes. A ticket gets created or updated — that's trigger territory. A ticket sits untouched for four hours — that's an automation. Nearly every "my Zendesk workflow didn't fire" mystery traces back to picking the wrong one of these two.
Both are condition-and-action rules, both live in Admin Center, and both look nearly identical when you're building them — which is exactly why admins mix them up. But under the hood they run on completely different engines, and knowing which engine you need is the whole game.
What exactly is a Zendesk trigger?
A trigger is an event-based rule that runs the instant a ticket is created or updated. Every single ticket event causes Zendesk to evaluate all of your active triggers, top to bottom, and run any whose conditions match.
Because they're instant, triggers own everything that needs to happen right now:
- Auto-assigning new tickets to a group based on subject, form, or channel
- Sending the customer an instant "we got your request" confirmation
- Tagging and prioritizing tickets the moment they arrive
- Notifying a Slack channel or webhook when a VIP customer writes in
The key mental model: no event, no trigger. A trigger will never fire because time passed. A ticket sitting quietly in a queue is invisible to every trigger you own — which is precisely the gap automations exist to fill.
What exactly is a Zendesk automation?
An automation is a time-based rule that Zendesk evaluates roughly once every hour, checking all non-closed tickets against your conditions. Instead of reacting to what just happened, automations react to what hasn't happened.
Classic automation jobs:
- Escalating a ticket that's been unassigned or unanswered too long
- Reminding customers on Pending tickets after a couple of days of silence
- Auto-solving tickets that have waited on the customer for a week-plus
- Nudging agents before an SLA target quietly slips past
Two constraints matter. First, the hourly cadence: automations are for hour-and-day timescales, not minutes — if you need something in five minutes, redesign the workflow around a trigger. Second, each automation must contain an action that cancels one of its own conditions (bump the priority it checked, add a tag it excluded). That's not bureaucracy — it's Zendesk forcing you to prevent the same automation firing on the same ticket every hour, forever.
Why didn't my trigger or automation fire?
Nine times out of ten, one of these five culprits:
- Wrong tool for the job. You built a trigger for a time-based condition, or expected an automation to react instantly. Re-read the one-line rule up top.
- Firing order. Triggers run top to bottom, and an earlier trigger can change the ticket so a later one no longer matches — or matches when it shouldn't. Order is not cosmetic; it's logic.
- ALL vs. ANY confusion. Conditions under "Meet ALL" must every one be true. One stray condition in the wrong section silently kills the rule.
- The nullifying action is missing or wrong (automations only). Zendesk may refuse to save it, or the automation fires once and never again — or hourly, forever.
- Something else already changed the ticket. Another trigger, a macro, or an integration modified the field your rule was checking. The Events log on any ticket shows the full audit trail — it's the single most underused debugging tool in Zendesk.
Which patterns need which tool?
A quick translation table for the most common workflows:
Build these as triggers
- Auto-assignment and routing — instant, event-driven by definition
- Received/updated notifications to customers and agents
- CSAT surveys — send when a ticket is solved (the solve is the event)
- Priority stamping based on customer tier or form answers
Build these as automations
- SLA warning nudges — "approaching breach" is inherently about elapsed time
- Pending-ticket reminders and auto-solves — silence is not an event
- Stale-queue escalations — unassigned for N hours, bump and notify
The pairing pattern is where it gets elegant: a trigger tags and routes the ticket at creation, then an automation watches the clock on that tag. Event tool sets the stage, time tool enforces the deadline.
How do you avoid trigger loops and rule sprawl?
Loops happen when a trigger's action causes an update that re-fires a trigger — sometimes itself, sometimes a partner in crime. The classic: two notification triggers that each update the ticket in a way the other one matches. Zendesk has some loop protection, but the real defenses are yours:
- Make triggers self-disqualifying — add a tag in the action, exclude that tag in the conditions.
- Prefer "Ticket is Created" over "Created or Updated" unless you genuinely need updates.
- Audit quarterly. Rule sprawl is real — dozens of accumulated triggers, half inactive in spirit but active in fact, interacting in ways nobody designed. Naming conventions and a shared numbering scheme cost nothing and save hours.
If your instance has reached the "nobody remembers why this trigger exists" stage, that's a solved problem — untangling business rules is bread-and-butter Zendesk consulting work for us. Ask us about a workflow audit before the loops multiply.
Frequently Asked Questions
What is the difference between triggers and automations in Zendesk?
Triggers are event-based: they run instantly whenever a ticket is created or updated. Automations are time-based: Zendesk checks them roughly once per hour against all non-closed tickets. Use triggers for immediate reactions like routing and notifications, and automations for anything driven by elapsed time, like escalations and reminders.
Why is my Zendesk automation not working?
The most common causes: the automation lacks a valid nullifying action (an action that cancels one of its own conditions), a condition sits in the wrong ALL/ANY section, or you expected it to run instantly — automations only run on an hourly cycle. Check the ticket's Events log to see exactly what evaluated and when.
Do Zendesk triggers run in a specific order?
Yes — triggers run in the order they're listed, top to bottom, and every trigger is evaluated on every ticket event. An earlier trigger can change the ticket in ways that affect whether later triggers match, so ordering is part of your logic. Reorder deliberately and audit the sequence regularly.