Zendesk Trigger Execution Order, Explained

A rule near the top of your trigger list can fire after a rule farther down. If you model Zendesk ticket triggers as a single pass, that outcome is easy to miss.

This guide explains the cycle, then follows a small example you can reproduce in a test environment. It covers Zendesk Support ticket triggers, not messaging triggers or time-based automations.

How Zendesk evaluates triggers

The configured trigger and category order determines where evaluation begins. When a trigger updates the ticket, Zendesk restarts checking the list, excluding triggers that have already fired. A trigger can be checked more than once, but fires at most once in the same cycle. See Zendesk’s execution-cycle documentation.

The important distinction is list position versus the order of actions that actually execute. A rule skipped on an earlier check can become eligible after another rule changes a field.

A worked example: an earlier rule fires later

The following is an illustrative configuration. Use a test environment with only these relevant rules and explicit starting values; other active rules can change the outcome.

Starting ticket: Priority = Normal, Group = Support, tags include order_demo and vip.

Rule A — route High-priority demo tickets (position 1):

• ALL: Tags contains order_demo; Priority is High.
• Action: Group = Escalations.

Rule B — raise VIP demo priority (position 2):

• ALL: Tags contains order_demo; Tags contains vip; Priority is Normal.
• Action: Priority = High.

Submit an update to the ticket without changing those starting values:

Check	Result	Ticket afterward
A: Priority is High?	No; A is skipped	Normal / Support
B: demo + VIP + Normal?	Yes; B sets High	High / Support
Restart: A checks again	Yes; A assigns Escalations	High / Escalations
Remaining checks	A and B have fired; neither acts again	High / Escalations

Expected final result: High priority, Escalations group. A executed after B even though A appears first in the list.

For a negative case, start a second test ticket at Normal / Support with order_demo but without vip. Neither rule should act. If that ticket changes, inspect other rules or integrations before attributing the result to this pair.

This trace demonstrates the documented cycle; it is not a screenshot of a customer incident or a claim that every live account will have only these two rules.

Why order creates conflicts

Suppose Rule C assigns General Support when Priority is Normal, while Rule D raises Priority from Normal to High. Both also require your demo tag.

With C first, the ticket can be assigned before its priority changes. With D first, the assignment condition can stop matching. Decide what you mean: “route tickets that started Normal” and “route tickets that are Normal when this rule checks” are different requirements.

Avoid fixing this by trial-and-error reordering. Write down which fields each rule reads, which it writes, and the final state you want. That gives you a testable reason for the chosen conditions and order.

The “last writer wins” problem

Add a third rule to the original A/B example:

Rule C — send demo tickets to General Support (position 3):

• ALL: Tags contains order_demo.
• Action: Group = General Support.

After B raises the priority and A assigns Escalations, C also matches and assigns General Support. The final group is General Support. A did act; its assignment did not survive.

The relevant “last writer” is the last assignment that actually executes, not necessarily the rule with the largest position number. Dependencies can make a higher rule eligible later.

For this example, if C is meant to handle only non-VIP demo tickets, add that distinction to C’s conditions. Retest both VIP and non-VIP cases. Do not rely solely on putting A below C: that can hide ambiguous ownership of the same field.

When investigating a real ticket, compare the final value with the relevant update in Events. An absent entry cannot establish that a rule was never checked or never acted: actions with no net field change may be absent from the log. The debugging checklist explains how to use that evidence.

How to manage execution order

1. Organize triggers by function

Zendesk recommends field updates first, assignments next, and notifications last. This is a useful starting order, not a substitute for reviewing dependencies. See the official ordering guide.

For each assignment or notification, ask: which earlier work must be complete, and what other rule could change those inputs afterward?

2. Reorder deliberately

Use the trigger list’s reorder controls when changing execution order. Sorting a column for viewing does not change execution order. Review category order too, and record the before/after placement so the change can be reviewed.

3. Give overlapping rules distinct responsibilities

Two rules assigning different groups may be correct if their conditions are mutually exclusive. Two broad rules that can both match need an explicit policy: which cases belong to each group?

Start by tightening that distinction. Do not disable a rule simply because a static check finds an overlapping pair; first confirm whether a real ticket can satisfy the relevant conditions and whether the result is unwanted.

4. Keep a small regression checklist

For each change, retain a positive case, a negative case, and a case where another rule writes the same field. Capture initial values, the update being performed, and the expected final state.

Use the sandbox and testing guide to choose an appropriate environment. A tag narrows a rule’s audience; it does not stop unrelated rules from acting on the same test ticket.

Use RuleScope to narrow the review

RuleScope highlights potential conflicting writes and order dependencies in the current trigger configuration. Use a finding to identify the rules worth tracing, then confirm the behavior with a concrete ticket scenario.

Static findings describe configuration risks. They do not prove that an incident happened, simulate every Zendesk execution path, or replace an end-to-end test. The Ticket debugger can help inspect condition results while preserving unknowns where the available context is insufficient.

Install RuleScope from the Zendesk Marketplace →