Zendesk Trigger Not Firing? A Debug Checklist
Find out whether a Zendesk ticket trigger missed a condition, had its action overwritten, or sent a notification that needs separate investigation.
A ticket stayed in the wrong group. A priority did not change. An expected email never arrived. Each can look like a trigger that did not fire, but they need different checks.
Start with one ticket, one update, and one expected action. Write down the ticket ID, update time, trigger name, and expected result. This guide covers Zendesk Support ticket triggers; messaging triggers and time-based automations have different execution rules.
1. Check if the trigger is active
Find the rule under Admin Center → Objects and rules → Business rules → Triggers, on the ticket triggers list. Confirm that you are inspecting the right trigger and that it is active. If you recently edited it, compare the current configuration with the one you intended to test. See Zendesk’s trigger management instructions.
Next, identify the event. Does the rule require Ticket is Created, while your test only updates an existing ticket? Those are different inputs. A useful reproduction must perform the event the rule expects.
If the intended action is “do this after four hours,” check whether the workflow needs an automation instead. Ticket triggers respond to creation and updates; elapsed-time workflows belong to Zendesk’s automation rules.
2. Verify the trigger conditions
Read the ALL and ANY groups separately. Every ALL condition must match. When ANY conditions are present, at least one must also match; an ANY match does not cancel an ALL failure. Check each field and operator against the official condition reference.
A small condition example
This is an illustrative configuration, not a customer incident:
- ALL: Ticket is Updated; Priority is High.
- ANY: Tags contains at least one of
vip. - Action: Group = Escalations.
Use a test ticket with the following inputs:
| Update being tested | Conditions | Expected result |
|---|---|---|
Create a High-priority ticket tagged vip | Updated fails | This rule does not assign the group |
Update a Normal-priority ticket tagged vip | Priority fails | This rule does not assign the group |
Update a High-priority ticket tagged vip | Both groups match | Rule assigns Escalations, unless a later action changes it |
If the intended workflow should also handle ticket creation, revisit the event condition deliberately. Do not move conditions between ALL and ANY just to make this one test pass: that can widen the rule to unrelated tickets.
“Changed to” versus “Is”
Priority is High checks a value. Priority changed to High checks a transition. In a test with no other rules changing priority, changing Normal to High matches both; a later comment-only update that leaves priority High matches is High, but not changed to High.
Record the value before the update as well as the value afterward. A screenshot of the current ticket alone cannot establish that a transition occurred.
3. Check execution order
Another rule can change the input your trigger sees. Check rules that write fields used in your failing condition: priority, group, tags, or custom fields.
For example, you submit a High-priority ticket, but a rule above the one you are testing sets Priority to Normal. A condition requiring High may then fail. Make a short list of candidate writers and compare their conditions with the same test ticket.
The order is not simply one pass from top to bottom. A rule that updates the ticket causes rechecking of rules that have not already fired. Work through the execution-order example before deciding that an earlier rule can never see a later rule’s changes.
4. Look for conflicting triggers
An action can take effect and then be overwritten. If the expected result is Group = Escalations, search for other matching rules that assign a group. Record which rule should own that assignment and under what conditions.
A rule appearing lower in the list is only a clue. Use the conditions and the actual update to work out which assignments can execute; see the last-writer-wins example.
Before changing production order, make a test case for the intended assignment and a second case that should keep its original group. A fix that routes both cases to Escalations has broadened the problem.
5. Understand the trigger cycle
A ticket trigger can be checked repeatedly during one cycle, but it fires at most once in that cycle. Do not diagnose a missing action using an assumed “14-step recursion limit.” Zendesk describes the behavior in its ticket trigger cycle documentation.
If a rule already acted earlier in the same cycle, a subsequent field change does not mean it will act a second time. A separate ticket update is a separate test: write down which update you are investigating.
6. Inspect the ticket events log
Open the ticket’s Events view and locate the relevant update. Compare changed field values, the actor, and notification entries with your notes. When an email notification is shown, you can inspect its associated content. Follow Zendesk’s Events guide for the current interface.
No event entry is not proof that a trigger failed its conditions. Zendesk notes that a trigger action with no net field change may not be logged. Events are useful evidence, not a list of every condition evaluation.
Likewise, a notification entry does not by itself prove inbox delivery. If the rule applied its expected field changes but the email is missing, investigate the notification recipient and delivery separately. For a webhook action, inspect the integration’s request/response evidence rather than treating it as an email problem.
7. Retest with a controlled ticket
Use a sandbox or a suitably isolated test setup. The trigger testing guide explains why adding a test tag alone does not isolate the rest of production.
- Set the starting values explicitly; do not assume a default priority or group.
- Use the same channel and actor role as the failing case.
- Perform the intended event: creation, a field change, or a comment-only update.
- Compare the expected final fields and notifications with the observed result.
- Repeat with a negative case that should not match.
Change one relevant part of the rule at a time. Keep the original configuration and the before/after test notes so that another administrator can review the result.
Where RuleScope helps
When several triggers interact, RuleScope can flag potential conflicts, contradictory conditions, redundancies, and order dependencies for review. Its Ticket debugger shows conditions as passed, failed, or unknown using the available ticket context.
That view can help narrow the next check. It is not a replay of every historical trigger version or a replacement for Events and delivery evidence. Confirm findings against the configuration and reproduce the behavior before changing a live workflow.
Tired of debugging triggers manually?
Review potential trigger conflicts, contradictory conditions, and order dependencies.
View on Zendesk Marketplace