In a previous issue of Internal Note, I wrote about the way I structured Views in Zendesk. For me, Views should reflect the way the tickets flow through Zendesk and should focus on work to be done instead of being used to categorise and report on tickets.
My approach is often in stark contrast to how others use Zendesk. Most customers have dozens of views and use views as filters to look into the work, with multiple views that show a subset of tickets sorted by category, group, or assignee.
This not only makes it easy to see what's outstanding and what the next actionable item is, but it also allows for a too granular set of conditions that might hide or omit some tickets from views.

I use a similar approach to the way I build and organize triggers in Zendesk. Instead of building my triggers ad hoc for the use case I need at that moment, throughout my years of experience as a Zendesk consultant, I developed a way to organize triggers that makes it very clear what each trigger does, and allows you to follow a ticket throughout the triggers so you can know exactly where a ticket will end up once all triggers have passed.

Triggers

Triggers in Zendesk are rule sets that are activated by an action on a ticket and can update the ticket or perform other actions as a result of this initial action.

They consist of a set of conditions (when they should run) and a set of actions (what should happen next). Since triggers update tickets, they can also activate other triggers through the actions they execute, making them ideal for chaining actions one after another.

A ticket is created and its category is set to "Refunds." Based on the category, the ticket should be assigned to the "Finance Team." We should notify the requester about when they can expect a reply from this team via a notification email.

When considering the above scenario, there are two approaches we can take in Zendesk.

1. We create a Refunds trigger that sets the category based on the content in the ticket or intent, then assigns it to the Finance Team and notifies the requester. All nicely combined in one flow.
2. We create three triggers:
   1. One that sets the "Refunds" category
   2. Another trigger that looks at tickets with a category updated to "Refunds, Invoices, or Payments" and assigns them to the Finance Team
   3. A trigger that sends out a notification to the requester for all assigned tickets

Most people will go for option one: a single trigger that bundles all Refund actions in one nice trigger. But personally, I prefer the latter of the two options and create three distinct triggers.

Why? Because if you need a trigger to handle "Refunds, Invoices, or Payments" and use the combined trigger option, you end up with three triggers that have very similar actions. If you ever want to update, for example, the assignment (e.g., start using queues) or the notification email (e.g., add auto-replies), you need to update three triggers with the same actions.

And since triggers perform a lot of actions, it becomes complex to update them, as they execute many actions at once, making it difficult to understand why they did or didn't run.

So, let me introduce you to my ideology when it comes to building triggers:

One trigger does one job

This means you have one trigger with a few or a lot of conditions and a single outcome. That outcome can be "raise the priority," "escalate to a webhook," "assign," or "send an email."

Sounds confusing? Let's dive in!