Zendesk Triggers: What They Are and How They Actually Fire
September 19, 2026
Triggers are the workhorse of a Zendesk instance, and the single most common source of “why did the ticket just do that?” This guide explains what a trigger is, the exact moment one runs, and the two behaviors that trip up almost every team.
What is a Zendesk trigger?
A trigger is an event-based business rule. It watches for a ticket being created or updated, checks a set of conditions, and, if they all pass, runs a set of actions. Notify a group, set a priority, add a tag, send a webhook, change the status: all trigger actions.
The key words are created or updated. Unlike automations (which run on a time-based schedule), a trigger runs the instant a ticket changes. If nothing about the ticket changes, no trigger runs.
When exactly does a trigger fire?
Every time a ticket is created or updated, Zendesk runs your entire active trigger list, top to bottom, in order. That ordering matters more than most people realize:
- A trigger low in the list sees the changes made by triggers above it in the same run.
- Two triggers that both set the assignee will “fight”, and the lower one wins.
- Re-ordering triggers can change behavior without changing a single condition.
So when a trigger misbehaves, the question is rarely “is the condition right?” It’s often “what ran before it in this update?”
The two behaviors that catch everyone
1. “Any update” fires more than you think
A ticket is “updated” by far more than an agent typing a reply. An API call, a side conversation, a light-agent comment, a tag change from another trigger, a status change from an automation. All of these are updates, and all of them run your trigger list again.
If a trigger’s only condition is “ticket is updated,” it will fire on events you never pictured. The fix is almost always to add a guard: check who made the change (end user vs agent vs a specific integration user), or require a specific field to have actually changed.
2. The silent new → Open promotion
Here’s a classic. A brand-new ticket has the status New. Many teams rely on New to mean “nobody has touched this yet.” But a surprising number of actions quietly promote a ticket from New to Open, including some of your own triggers and any API update that sets an assignee.
Once a ticket leaves New, it usually can’t go back, and any view or report that keys on “New” silently stops seeing it. If your “untouched tickets” view is mysteriously empty, this is almost always why.
The fix is to be deliberate: guard the triggers and integrations that touch fresh tickets so they don’t set an assignee (or otherwise promote status) unless you actually want New to end.
How to keep triggers from fighting each other
A few habits prevent most trigger chaos:
- Guard every trigger with an author check. Decide whether it should run for end users, agents, or a specific integration user, and say so explicitly.
- Require the field to change, not just exist. “Priority is Urgent” fires on every later update too; “Priority changed to Urgent” fires once.
- Mind the order. Group related triggers together and know which one is meant to win.
- Use a dedicated integration user for API updates, and exclude it from triggers that shouldn’t react to automated changes. This is the cleanest way to stop update loops.
- Audit periodically. Trigger lists grow. Every year or two, half of them are doing nothing, and two of them are quietly undoing each other.
The short version
- Triggers run on create or update, through the whole list in order, every time.
- “Any update” means far more events than agent replies, so guard by author and by changed fields.
- Watch the New → Open promotion; it silently breaks “untouched” views.
- When a trigger misbehaves, look at what ran before it, not just its conditions.
If your instance has grown a thicket of triggers nobody fully understands anymore, that’s exactly what a health check untangles.
Written by Opsnest, independent, US-based Zendesk specialists. Want a second pair of eyes on your instance? Get a free Zendesk Health Check.