If you’re like most Zendesk admins, the longer your team uses Zendesk the more complex your instance will grow. You’ll add more and more triggers, creating more chances for triggers to overlap in functionality, accidentally overwrite each others' changes or become obsolete altogether. 

To avoid the pitfalls, data errors and troubleshooting that arise when these errors occur, Zendesk provides several ways you can organize your triggers to avoid these unhappy accidents. The right trigger organization strategy helps you know what triggers and automations might be impacted by a change and quickly identify what triggers you’re using in a given ticket workflow.

Zendesk trigger behaviors

Zendesk triggers have a few important behaviors and features that are critical to understand (although not always intuitive) when organizing your triggers. Once you understand these concepts, it’s way easier to create precise trigger rules and a smart organization system. 

‍

Trigger order matters

Trigger order is a common source of frustration when troubleshooting and creating new triggers. The order in which the triggers appear in the Zendesk admin view is the order in which triggers are checked and executed. 

This means if a trigger makes changes to fields, those changes impact whether or not a trigger further down the list runs. If you’ve got a trigger that only fires when a Billing tag is applied but an earlier trigger removes that tag, your other trigger won’t fire. 

To an agent, this often appears as if a trigger is running at the wrong time based on their update. 

‍

Triggers can overwrite each other's changes

If two triggers edit the same field data and their rules both say they should fire, then the second trigger's changes will overwrite the first trigger’s changes. 

Although often seen as a nuisance and difficult to troubleshoot, this can be a valuable feature when building complex workflows. 

For example, your routing triggers identify that the ticket should go to a frontline team and sets the appropriate group, but a later workflow trigger checks that this is a VIP customer and re-routes the ticket to a specialized VIP team. If the VIP trigger couldn’t overwrite the earlier trigger, this ticket would route incorrectly and an important customer might get subpar service.

‍

“All” vs “Any” in Zendesk triggers

To ensure triggers fire correctly, you need to be very precise about defining your trigger rules. Zendesk triggers include two main sections:

• ALL - To run, a trigger must meet all conditions specified in this section. Zendesk triggers must include at least one “ALL” condition.
• ANY - To run, a trigger must meet any of the conditions specified in this section. It’s not required to include “ANY” conditions, but when you do, you’ll normally have several conditions that the trigger will be looking for.

‍

‍

Check out this post for more information on deciphering whether your trigger needs an ALL or ANY condition.

‍

Organizing Zendesk triggers

Given these behaviors, it’s important to organize your triggers in a way where actions run in the expected sequence and only operate against expected tickets. The best way to do this is to separate your trigger categories in line with your ticket lifecycle. 

Most ticket lifecycles operate something like the below: 

‍

‍

Depending on your implementation and team size, you may not need all the categories above. For example, a small team at a new startup might have minimal routing, surveys and workflow logic.

As your services become more complex, you will probably have triggers that execute in each of these areas—and you may even create more categories for better organization. For instance, you might run different types of surveys for different brands, and want to handle responses to each type of survey differently. This means you could split the survey category into multiple subcategories to keep tickets and triggers for each brand separate.

Let’s dive in to how organizing your Zendesk triggers in line with these ticket lifecycle categories might look. 

‍

Open actions

The first step to setting up Zendesk triggers is to establish the actions that will apply to tickets immediately when they are opened. These actions include setting ticket fields like priority, status and tagging. 

Defining these actions at the outset ensures the metadata settings are applied consistently to each ticket. This maintains a common workflow experience and standardizes what your agents see on every ticket.

‍

Routing

Routing tickets makes sure that the right agents or groups consistently have access to the ticket faster. This involves creating triggers that apply to specific types of tickets, such as those with certain tags, user field values or keywords in the subject line. 

By routing tickets in a consistent manner, you will have the right agent working on tickets faster.

In some organizations, Open Actions and Routing can be combined. If you have a trigger that’s setting a ticket to ‘Critical’ priority upon opening, then it might also route the ticket to a specific user or group. 

‍

Workflow automation

A workflow is any distinct flow of your tickets. The flow differs for each type of ticket—a ticket requesting a refund will have a different action flow than a ticket that reports a defect. 

That means that this Workflow Automation category will probably actually include multiple subcategories. You might set up a subcategory for refund-related triggers and another for defect-related triggers. 

A good way to approach this is to think about the different ticket types, brands and groups in your Zendesk instance. Where are the ticket flows similar? Where do they diverge? Where would it make sense to have a separate category of triggers and automations? 

The goal of splitting these up is to have specific triggers meaningfully grouped for only the workflows that require them. Don’t create unnecessary categories—that just makes things more complex—but be strategic about separating out categories where it’s appropriate.

‍

Shared workflow triggers

These are triggers that are shared between one or more workflows. It’s likely that many of your tickets require the same actions and triggers with identical logic, so you probably don’t need many subcategories here.

This category could occur before or after Workflow Automation. It could also replace it altogether, or you might need to split up this category to have some triggered run before your standard workflows and have others run after. 

Remember, the order of your triggers affects how they execute, so get granular and think about each specific step in the process. 

‍

Close actions

The ticket lifecycle doesn't always end when a ticket closes. 

When a ticket is marked Closed or Solved, there may be some action you want to take to close out the workflow. This could be sending out a survey to the customer or updating an integrated tool. This category includes all of those “post-closure” triggers. 

If you receive a negative CSAT survey, you may want to re-open the original ticket and assign it to a customer success management view for someone to follow up with the frustrated customer.

‍

Notification triggers

Typically, your notifications should execute at the end of all other triggers. 

This ensures that notifications aren't duplicated somewhere else in the process and that they only fire after all triggers have run and (potentially) edited the tickets.

You can set up tons of different custom notifications within Zendesk, so the triggers and subcategories you include here will vary significantly based upon your needs.

Use meaningful names

Another best practice to keep your triggers organized is to get strategic with your naming conventions. 

Make sure all of your triggers have a name and a description that clearly identifies what it does and, most importantly, the business reason for the trigger. 

As your Zendesk instance evolves over time—like when you launch new products or when employees change roles—the reason for some triggers can become unclear. Keeping the names and descriptions up-to-date will give future administrators an easier way to troubleshoot when things go wrong. 

A great naming convention would be in the format of [Reason for Trigger] - [workflows].  

For example: 

• Route Ticket to Tier 2 Support - All Escalated Tickets
• Send CSAT Survey on Ticket Close - Tier 1 Support Tickets Only

Similarly, spending the time to write a detailed description is worthwhile in the long term. A description should include things like:

• The business reasons for the trigger
• Any related triggers
• Rule descriptions, especially any rules that aren't immediately obvious why they are there
• When to update the trigger (if known). For example, you may need to update some triggers to include or exclude a new group being created.

‍

Keep your Zendesk triggers organized to streamline your support operations

As you scale your support organization, your Zendesk instance will need to evolve to accommodate your business needs. 

One way to provide a consistent and efficient service to your customers is through trigger automations. Triggers can supercharge your support team, but only when they work correctly. As you build out more triggers, they regularly need to be evaluated, edited and adjusted.

Creating an organization plan for your triggers and sticking to it will save you many future headaches and countless hours of troubleshooting.