Zendesk Triggers Not Firing: How to Debug Them

The good news: Zendesk records exactly what happened on every ticket, so you almost never have to guess. This guide shows you the authoritative way to debug — read the ticket Events log to see which triggers fired and why — then walks the causes ranked by how often they're the real culprit, with a concrete fix for each. Everything below is checked against Zendesk's own documentation; Zendesk revises its UI periodically, so confirm labels in your own account.

The symptom: "my trigger isn't firing"

"Not firing" usually shows up as one of these:

• A trigger that should assign, tag, or set a field leaves the ticket untouched.
• A trigger that should send an email notification to the requester or a group sends nothing.
• The trigger was working and silently stopped after someone edited the account.
• The trigger fires on some tickets but not the one you're staring at.

All four are diagnosable the same way. Resist the urge to start tweaking conditions blindly — that's how a small problem becomes three. Read the evidence first.

Step 1 — Debug authoritatively: read the ticket Events log

Every ticket in Zendesk keeps a complete audit trail of who (or what) changed it. This Events log is the single most useful trigger-debugging tool, because it tells you whether your trigger fired at all — which immediately splits your problem in two: the trigger didn't run vs. it ran but did something you didn't expect.

To open it on any ticket:

• Add /events to the end of the ticket URL (e.g. …/agent/tickets/12345/events), or
• In the Agent Workspace, open the ticket, click the Conversations menu, and choose Events.

You'll see the full list of updates for that ticket — properties added, removed, or changed, plus any notifications sent — including the ones made by business rules. Per Zendesk's Viewing all events for ticket updates, each automated change is attributed to the trigger that made it. A fast trick from Zendesk's troubleshooting doc: use your browser's find (⌘/Ctrl-F) and search for the word "trigger" to jump straight to business-rule activity.

Now you can read the result:

• Your trigger's name appears in the events for that update → it fired. If the ticket still looks wrong, your problem is the trigger's actions (or a later trigger overwriting them), not whether it ran. Skip to causes 1–2.
• Your trigger's name is absent → it did not fire on this update. Its conditions weren't met, or it never got the chance to run. Work through causes 3–9.

On Enterprise plans, go one level deeper. In the events list you can click a trigger's name to view the exact version of the trigger that fired — its precise conditions and actions as they were configured at that moment. That's invaluable when a trigger was edited afterward: you see what actually ran, not what the rule looks like today. One important caveat: this only works for triggers that appear in the events log — i.e. ones that fired. A trigger that didn't fire isn't listed, so there's no per-condition "red X" to click into for a rule that never ran. To debug a trigger that never fired, open the trigger itself and read its conditions against the ticket by hand (the next sections show how). (Some community and partner guides describe a green-check/red-X per-condition view; Zendesk's native capability is the "view the version that fired" inspector described here — confirm the exact UI in your own account.)

One important limitation to know before you trust an empty log: the events log records a business rule's actions only when they produce a net change to the ticket's field values. If a trigger fires but its action sets a field to the value it already had (no change), you may not see a log entry — so "nothing in the log" isn't always "the trigger didn't run." (This behavior is documented by Zendesk partners rather than in the core trigger article, so verify in your own instance.) For email specifically, Zendesk does record the outgoing notification as an event.

With the log read, here are the causes — ranked by how often they're actually to blame.

The causes, ranked by likelihood — and how to fix each

1. The trigger is deactivated (or got deactivated for you)

The most embarrassing and most common one. A trigger that's toggled inactive does nothing, and Zendesk will deactivate a trigger automatically if it references a field, group, or view that was deleted or renamed.

Confirm: In Admin Center → Objects and rules → Business rules → Triggers, switch to the Inactive tab. If your trigger is there, that's your answer. Fix: Reactivate it. If it keeps deactivating, it's pointing at something that no longer exists — open it and look for a condition or action referencing a deleted custom field, group, or form, and repoint it.

2. Trigger order — an earlier trigger already changed (or "satisfied") the ticket

This is the subtle one that fools experienced admins. Triggers run top-to-bottom in the exact order they're listed on the Triggers page (per About triggers and how they work). An earlier trigger's action can change the ticket in a way that makes a later trigger's conditions no longer match — or it can do the job first, so by the time your trigger is checked, there's nothing left to do.

Zendesk's execution model matters here: after a full top-to-bottom pass, if any trigger fired, the whole list runs again from the top against the now-updated ticket. A given trigger fires at most once per cycle, and Zendesk has loop protection so this can't run forever (the exact cycle ceiling isn't published).

Confirm: In the Events log, look at what fired before your trigger and what it changed. If an earlier trigger set the status, assignee, or a tag your trigger depends on, that's your interference. Fix: Reorder. Drag your trigger above the one that's stealing its conditions, or tighten the earlier trigger so it doesn't overreach. As a rule, put routing/assignment triggers in a deliberate sequence and keep notification triggers after the triggers that set the values they announce.

3. Conditions too strict, or the wrong ALL vs ANY

If the log shows the trigger didn't fire, conditions are the usual reason. The killer detail is the difference between the two condition blocks: under Meet ALL of the following conditions, every listed condition must be true; under Meet ANY, only one needs to be. Pile too many specifics into ALL and you can build a trigger that essentially never matches.

The classic self-defeating mistake Zendesk calls out: putting two ticket statuses in the ALL block (e.g. Status is Open and Status is Pending). A ticket can only ever have one status, so that trigger can never run. Those belong in ANY.

Confirm: Open the trigger (Enterprise: use rule analysis in the events log) and read each condition against the actual ticket — channel, organization, group, tags, form. One mismatch in ALL is enough to block everything. Fix: Move "one of several" conditions into the ANY block, loosen over-specific values, and remove conditions you don't truly need. Save, then re-test on a fresh ticket.

4. You wanted an automation, not a trigger (event-based vs. time-based)

This is the single biggest conceptual mix-up, and it's worth stating plainly: triggers run on an event — the moment a ticket is created or updated. They do not fire as time passes. If your rule is "email the customer 24 hours after the ticket goes Pending" or "escalate a ticket that's been open 3 days," no trigger will ever fire, because nothing is updating the ticket when that time elapses.

That's the job of automations, which are time-based and run roughly once an hour using conditions like Hours since (see Zendesk's Using the Hours since condition). For the full breakdown, see our guide to Zendesk automations vs. triggers.

Confirm: Does your rule depend on time elapsing with no agent or customer action? Then a trigger is the wrong tool. Fix: Rebuild it as an automation in Admin Center → Objects and rules → Business rules → Automations, with a time-based condition and a nullifying condition so it stops re-running.

5. Closed (or "solved-then-closed") tickets — triggers don't fire there

Triggers do not run on closed tickets. The one exception is the single update that transitions a ticket to Closed (and that's excluded for the automatic system closure that happens ~28 days after Solved). So a trigger you expect to run "on update" of a long-resolved ticket simply won't.

Confirm: Check the ticket's status. If it's Closed, that's why — and note Closed is final; it can't be reopened. Fix: Don't rely on triggers for post-closure work. If you need late-stage behavior, act while the ticket is still Solved (before the 28-day auto-close), or handle it with a follow-up ticket.

6. Requester / "Notify by" / channel condition mismatch

Notification triggers often carry conditions the author forgot — Channel is, Ticket is created by (end user / agent), Organization is, or a specific requester. If the ticket came in through a channel the trigger excludes, or was created by an agent when the trigger only matches end-user submissions, it won't fire. Zendesk's troubleshooting doc names this directly: a condition on a specific organization or channel that the ticket doesn't meet will stop the trigger.

Confirm: Compare the ticket's actual channel and requester against the trigger's conditions in the log. Fix: Broaden or correct the channel/requester condition, or move it to ANY if you meant "any of these channels."

7. The action's prerequisite isn't met (comment / public reply / specific channel)

Some actions only do anything in the right context. An action set to send a public reply does nothing useful if there's no comment, and notification text that pulls a ticket placeholder can come out blank if that field is empty. The trigger may technically "fire" while appearing to do nothing.

Confirm: In the log, the trigger fired but the visible result is missing → inspect the action, not the conditions. Fix: Make sure the triggering update actually includes what the action needs (a comment, the right channel), and check placeholders resolve to real values.

8. A nullifying / "is not" condition that quietly excludes your case

Conditions like Status is not Closed or Tags contains none of the following are there to stop re-firing, but they also silently exclude tickets you might have wanted. A leftover Ticket: Status — Less than — Solved or a stale tag exclusion can be exactly why this ticket was skipped.

Confirm: Read every "is not / less than / none of" condition against the ticket. Fix: Adjust the exclusion so it scopes out only what you intend.

9. Cascade limits — and edits you didn't actually save / a stale test ticket

Two practical traps to close out:

• Cascades: actions applied by one trigger can affect how other triggers run and fire on the same update. If you've got many cross-referencing triggers, an update can cascade and a deep-chain trigger may not get its turn within the cycle limits. Simplify the chain.
• Unsaved or untested edits: the boring-but-frequent finish. You changed the trigger but didn't click Save, or you're re-checking an old ticket that was updated before your change. Triggers only act on updates that happen after you save. Always validate on a brand-new test ticket.

A note on "trigger not sending email"

If the Events log shows your trigger fired but the email never arrived, the trigger isn't your problem — delivery is. Zendesk's troubleshooting guidance points to email-specific causes: a notification action that targets the wrong recipient, CC/recipient configuration, suppressed or bounced addresses, or the message landing in spam. Verify the "Email user" action points at the right party (requester vs. assignee vs. group), then follow Zendesk's email delivery checks. Debug the trigger and the email as two separate layers — the log tells you which one to look at.

Prevention: triggers that stay debuggable

• Name triggers descriptively (Notify — assign agent on new web ticket) so the Events log reads like plain English.
• Order deliberately. Group by purpose — capture/normalize first, then route/assign, then notify — and document why.
• Add a nullifying condition to every trigger so it can't re-fire in a loop, and keep cascades shallow.
• Test on a fresh ticket after every change, and skim the Events log to confirm the right rule fired.
• Audit quarterly. Deactivate dead triggers and fix any that reference renamed fields before Zendesk deactivates them for you.

For the underlying concepts — conditions, actions, and how triggers fit the wider ticketing model — see Zendesk triggers explained and how the Zendesk ticketing system works.

Where AI fits in

Triggers are excellent at deterministic plumbing: if this exact thing happens, do that. They route, tag, and notify. What they can't do is understand a ticket — they fire on conditions, not on meaning, which is why a brittle stack of overlapping triggers is so often the thing you end up debugging.

That's the layer an AI agent like Macha adds. To be clear about positioning: Macha isn't a help desk and it doesn't replace Zendesk — it runs on top of your existing Zendesk. Where a trigger can only route a "where's my order?" ticket to a queue, an AI agent reads the actual question, pulls from your knowledge base and past tickets, and can resolve it in the thread — while still handling the housekeeping (tagging, status, escalation with full context) that you'd otherwise wire up trigger by trigger. It's complementary: keep your triggers for deterministic routing; let an AI agent handle the judgment calls.

The honest framing: it's another integration to configure, and it's only as good as the knowledge you connect. On cost, Macha bills per AI action — any automated step it takes, whether drafting a reply, tagging, or resolving — not per closed ticket, because most automation is work done along the way, not a tidy one-to-one "resolution." If you want to see it against your own ticket flow, 7-day free trial, no credit card required.

Frequently asked questions

How do I see if a Zendesk trigger fired on a ticket? Open the ticket and add /events to the end of the URL, or click Conversations → Events in the Agent Workspace. The Events log lists every update, including which triggers fired and what they changed. Use ⌘/Ctrl-F and search "trigger" to find business-rule activity fast. On Enterprise, click a trigger's name in the log to see why it fired.

Why is my Zendesk trigger not working even though the conditions look right? Most often a different trigger ran first and either changed the ticket so your conditions no longer match, or did the job before your trigger was checked. Triggers run top-to-bottom in list order. Check the Events log for what fired before yours, then reorder. Also confirm the trigger isn't deactivated and that you're testing a fresh ticket created after you saved.

Why does my trigger work for some tickets but not others? A condition is matching only a subset — usually channel, organization, requester, or a tag. Open the trigger and compare its conditions against a ticket that didn't fire, field by field, and check whether something belongs in the ANY block rather than ALL.

My trigger should send an email but nothing arrives — why? Check the Events log first. If the trigger fired, it's a delivery issue, not a trigger issue: verify the Email user action targets the right recipient, check CC/recipient settings, and look for bounced/suppressed addresses or spam filtering. If the trigger didn't fire, debug the conditions instead.

What's the difference between a trigger and an automation? Triggers are event-based — they run the instant a ticket is created or updated. Automations are time-based — they run about once an hour and act on elapsed time using conditions like Hours since. If your rule depends on time passing with no ticket update, you need an automation, not a trigger. See automations vs. triggers.

Can a trigger fire on a closed ticket? No. Triggers don't run on Closed tickets, except for the single update that transitions a ticket to Closed (and not the automatic system closure ~28 days after Solved). If you need behavior after resolution, act while the ticket is still Solved or use a follow-up ticket.

The bottom line

When a Zendesk trigger isn't working, don't guess — read the ticket Events log (/events or Conversations → Events), and on Enterprise click a fired trigger's name to see the exact version that ran. That one step tells you whether the trigger ran, which splits every problem into "it didn't fire" (check deactivation, order, conditions, ALL vs ANY, channel/requester, closed status, or whether you actually need an automation) or "it fired but did the wrong thing" (check its actions and any later trigger overwriting them). Triggers are event-based, run top-to-bottom, and a deliberate order plus a nullifying condition prevents most of the trouble before it starts. Debug from the evidence, fix one cause at a time, and re-test on a fresh ticket.

Debug method and behavior verified against Zendesk's official documentation, June 2026. Zendesk updates its product periodically — confirm labels and plan-specific features (e.g. Enterprise rule analysis) in your own account.