Triggers are an excellent way to automate your ticketing workflows but there is a science to how you should arrange them. As we all know, the system evaluates them in order. But since the trigger cycle starts over from the beginning each time a trigger is fired, things can get complicated. Partway down the line, a trigger could make an update to a ticket so it now satisfies a condition of an earlier trigger that hadn’t previously fired. If you have a lot of triggers, that’s troublesome, and I used to struggle with a good way to keep them orderly.

Each time you add a new trigger, you’re faced with that same dilemma of where it should fit into that lineup. This is doubly challenging for Zendesk admins who have just joined the company and are still trying to get a lay of the trigger land.

In this article, I share my approach to trigger management, and how to more easily resolve these questions at scale.

A brief history on trigger order

Before there was a native way to categorize triggers, I relied on a strict naming convention to help me bucket similar groups of triggers together. Essentially, I’d add a “label” to the start of the name, to denote the category. This helped my team and me understand what the trigger did at a glance. For example:

Add escalation tag when a ticket is reassigned from Group B to Group C.

When it came to the actual ordering of my trigger list, I’d group all triggers in the same category together (e.g. ‘Add Tags’ triggers), which worked well. Anytime I needed to add a new ‘Add Tags’ trigger, I knew exactly where it should go in my trigger list.

Then, last year, Zendesk released Trigger Categories to help admins keep their trigger list organized in accordion folders, so I no longer need the naming convention.

Zendesk also released the ability to search and filter your triggers list, which is incredibly helpful, as it allows admins to understand which triggers are based on a specific condition or action. For example, if you’re thinking of phasing out a specific group or ticket field, you could use this filter function to understand what triggers would need to be updated or deleted in conjunction with this change.

But it didn’t solve the broader real question, which still stands: Where should you even begin when it comes to ordering your triggers and determining what categories make sense for your organization?
‍

My advice: Follow the ticket lifecycle

When it comes to ordering triggers, I like to take a step back and think about the entire ticket lifecycle from ticket creation to resolution. When it comes to the specific trigger I’m adding, where exactly in this lifecycle would it fall? If the trigger should fire upon ticket creation, it’s best to put those at the top of your list. I also prefer to have triggers that can fire at any point in the ticket lifecycle at the bottom, so that I don’t have to consider them when thinking through the ordering of new triggers or categories.

For example, let’s say you have multiple ticket groups in Zendesk, all of which have different Ticket Received email messaging. In this case, you need to route the ticket to the correct group before you send the Ticket Received notification. If you mixed up that order, you could be sending the wrong version of the Ticket Received notification, and then reassigning the ticket to the correct group.

Once you have a sense of that order of operations for your company, you can bucket that order of operations into pretty reliable categories. For example:

Tier 1: Actions that must happen upon ticket creation

• Inbound routing rules
• Setting the schedule
• Updating the ticket’s priority to Urgent, based on keywords
• Ticket Received notification rules

Tier 2: Actions that update ticket properties to either fire or prevent the firing of triggers further down the list

• Add Tags
• Selecting a ‘Do not send CSAT survey’ checkbox for specific types of tickets

Tier 3: Actions that  occur based on the second tier of triggers

• Sending Slack notifications for tickets with a specific tag
• Sending CSAT surveys

Tier 4: Actions that remove specific ticket properties

• Remove certain tags after the next public agent comment so that specific workflows can or cannot be run through again after the next ticket update.

Tier 5: Actions that can happen anytime.(For simplicity, I place these last so I just don’t have to think about them when determining ordering for new triggers)

• Adding a customer’s Success Manager as a Follower for tickets from their accounts
• Integrations (e.g. Salesforce, PagerDuty)

Example Zendesk trigger categories

Below is an example of what your trigger category might look like as well as a trigger you might find within each category.
‍

Fewer headaches and easier trigger management

While the triggers and categories will vary from company to company, taking time to document your ticket lifecycle and create corresponding Trigger Categories will save you lots of time and many headaches. And the sooner you start enforcing order in such an open-ended system, the better because it will save you countless hours to do this now versus even a year from now when you’ve built far more triggers.