How to Set Up Zendesk Triggers and Automations Correctly

Zendesk triggers run the moment a ticket is created or updated; automations run on a clock — every hour by default — against tickets that match conditions. Confusing the two is the top cause of duplicate emails and notifications that fire at 3am.

If you remember one line: triggers react to events, automations react to time.

What’s the actual difference between a trigger and an automation?

Feature	Trigger	Automation
Fires when	A ticket is created or updated	A scheduled scan (hourly, or every 10 min on higher plans)
Typical use	Notify, assign, set priority	Escalate stale tickets, send reminders
Order	By position, top runs first	By position, top runs first
Can email requester	Yes	Yes
Default set	7-9 active by default	A few, mostly escalation

Both live under Admin Center > Objects and rules > Business rules. Both use the same condition syntax. The difference is entirely the clock.

Step 1: Audit the default triggers before adding yours

A new Zendesk instance ships with a set of active triggers — “Notify requester of received request”, “Notify assignee of assignment”, and similar. Most duplicate-email complaints trace back to a custom trigger overlapping one of these.

Open the trigger list, sort by position, and read what’s there. Disable anything you don’t understand rather than layering a new rule on top. You can always re-enable it.

Step 2: Learn the ordering rule

Zendesk evaluates triggers in list order, and a trigger that changes a field can cause later triggers to match or stop matching. This produces maddening behavior: two identical-looking tickets get different emails.

The fix is a convention. Put broad notification triggers at the bottom, specific ones at the top, and never let two triggers both send a public comment for the same condition. Drag to reorder — the position number is load-bearing.

Step 3: Build the three triggers every team needs

Start with these. Not twenty.

• First response acknowledgement. Condition: ticket created. Action: public comment with expected response time and a link to the help center. This alone deflects a chunk of second messages.
• High-priority group assign. Condition: priority is Urgent. Action: assign to the escalation group, add tag urgent, notify a Slack channel via webhook.
• Reopen detection. Condition: status changed to Open from Solved. Action: remove the solved_by_bot tag, reassign to previous assignee, notify.

Each of those is a two-minute build. Most teams stop needing more once these exist.

Step 4: Automations are for neglect, not speed

Automations exist to catch tickets nobody touched. The useful set is small:

• Pending reminder. Status is Pending and hours since update > 72 → email requester asking if resolved.
• Unsolved escalation. Priority is Normal or High and hours since created > 24 → notify group lead.
• Snooze expiry cleanup. Status is On-hold and hours since update > 168 → move to Open and reassign.

Notice the pattern: hours, not minutes. An automation firing every 10 minutes on a 24-hour condition is a notification generator, not a workflow.

Step 5: Test with a real ticket, not the preview

Zendesk’s trigger tester shows which triggers would fire — useful, but it doesn’t show the final aggregate effect. Create a test ticket from a personal address, then read what the requester actually received. Check for duplicate emails, missing signature, and whether internal notes leak.

One caution: automations don’t run instantly. If you build a 1-hour condition and refresh for a minute, nothing will happen. Wait for the next cycle, or use a trigger instead.

Why do my triggers keep sending duplicate emails?

Three causes, in order of frequency. One: an overlapping default trigger you didn’t disable. Two: the condition “Ticket is updated” combined with an action that updates the ticket — the update re-fires the trigger. Three: both a trigger and a webhook notify the same channel.

For the second, add a guard: condition Tags does not contain notified_first, action adds that tag. Tags are the cheapest loop breaker in Zendesk.

When should you use a view instead of a rule?

If nobody needs to be told, nothing needs to fire. A view showing “Urgent, unassigned, older than 2 hours” that an agent checks each morning costs nothing and creates no noise. Rules should produce an action a human can’t do by looking at a screen.

For teams under about 5 agents, three triggers and two automations are genuinely enough. The rule count tends to grow with the number of things nobody owns.

Quick Summary

• Triggers fire on ticket events; automations fire on a schedule (hourly by default).
• Execution order is list position — reorder before debugging weird behavior.
• Disable overlapping default triggers instead of layering new ones.
• Automations should key off hours or days, not minutes.
• Add an anti-loop tag guard to any trigger that updates the ticket itself.