Zendesk Trigger & Automation Audit template.

What's inside — the exact file

This is the complete template, not a sample. The rows are worked examples — replace them with your data (and delete them before any platform import).

What this template is for

Trigger sprawl is the most common disease in mature Zendesk instances: years of additions, no deletions, and eventually nobody can predict what firing a ticket update will cause. This worksheet inventories every trigger and automation with a keep/kill/fix verdict — the audit we run at the start of nearly every Zendesk engagement.

The rows come pre-filled with the failure patterns we find most often: notification loops, double-notifies from overlapping conditions, zombie triggers referencing deleted groups or fields, and automations that fire hourly for no measurable reason. Use them as a checklist for what to hunt in your own instance.

How to use it, step by step

1. Export your trigger and automation list. Work through Admin Center's business rules pages methodically — every active trigger and automation gets a row. Inactive ones worth keeping get a row too, marked in notes.
2. Summarize conditions and actions in plain English. One sentence each. If you can't summarize what a trigger does in a sentence, that's a finding in itself — flag it for the fix column.
3. Pull the fire counts. Zendesk shows usage on each business rule (last 7 days / hour for automations). A trigger that hasn't fired in months is a deletion candidate; one firing thousands of times a week deserves a design review.
4. Issue verdicts: keep, kill, or fix. Be ruthless. 'Nobody remembers why' plus 'zero fires' equals kill. Overlapping conditions equal consolidate. Missing references equal fix or kill.
5. Kill in order, watch for a week. Deactivate (don't delete) the kill list, watch a normal week of ticket flow, then delete. Deactivation is your undo button.
6. Put a re-verification date on everything kept. The last_verified column turns this from a one-off cleanup into a standing control — re-run the audit every quarter or two.

What each column means

Common mistakes to avoid

• Deleting instead of deactivating — you lose the undo button and the configuration history in one click.
• Auditing triggers but ignoring automations, which quietly implement half of most SLA and escalation logic.
• Judging by name instead of conditions — 'Notify assignee' triggers that actually notify entire groups are a classic double-notify source.
• Killing a 'useless' trigger that a Marketplace app or integration depends on — check for tag-based conditions other systems consume before pulling anything.

Questions, answered

What's the difference between a trigger and an automation?

Triggers fire immediately when a ticket is created or updated and their conditions match. Automations run on a schedule (roughly hourly) against time-based conditions — 'pending for 48 hours' is an automation, 'ticket created via chat' is a trigger.

How do notification loops happen?

Trigger A updates a ticket, which fires trigger B, which updates the ticket again and re-fires A — or an email notification generates a reply that re-opens the loop. Any trigger whose action can satisfy another trigger's condition deserves a hard look.

How often should this audit run?

Quarterly for instances under active change, twice a year for stable ones. The audit is dramatically faster the second time — the first pass is the archaeology; every pass after is maintenance.

This is a Market Disrupt worksheet, not a vendor file. Import-format templates follow each platform's documented layout as of July 2026 — platforms evolve, so validate against current documentation before a large import.