You’re probably reading this because you manage multiple Zendesk instances, each with many triggers, many of which are complex. Meaning, they have many conditions that refer to a variety of business rules and fields.

If any of those rules and fields changed, you’d never know, and in some cases, your triggers would no longer fire. The conditions would never be satisfied and you’d probably never learn about it until long after hundreds or thousands of people stopped receiving support.

How do you manage that sort of complexity in a system as flexible as Zendesk? In this article, I’ll walk through how it’s typically handled. Then I’ll walk through how you could handle it much more quickly with the free tool, Salto.

‍

Why triggers break

Triggers tend to break because Zendesk is a wonderfully flexible system. If you want to change the underlying architecture upon which the triggers are based, it won’t stop you. There isn’t a native way for Zendesk to see the downstream ramifications of such changes, like what will happen if someone deletes an option on a ticket field.

But once that field is deleted, the side effects begin—the status of all the related tickets stops updating. The user doesn’t get the email she’s supposed to get, the ticket never reaches the agent, and the customer is effectively ignored.

This problem of having your triggers built on a foundation that’s easily changed is not limited to just triggers and field options. There are lots of scenarios in Zendesk where you’re allowed to modify or remove an object that breaks a rule, and you never get an alert.

So how do you compensate for it? Or if you do notice a trigger is broken, how do you find out which trigger it is, or which field change caused it? You have to be able to do three things:

#1. Find the broken business rules (in this case, triggers)

#2. Understand whether modifying or removing a specific object (in this case, a field option) would affect any business rules

#3. Get notified if a rule breaks so you can start this cycle over

And unfortunately for administrators, doing all that in Zendesk is reasonably time consuming.

• To find a broken business rule, you have to already know what trigger is misfiring. (Perhaps you’re the one who built it, which would be lucky.) Or, more likely, you have to go through every single trigger, reading all the conditions and actions.
• To understand if an object is affecting a business rule, you can go to “rule analysis,” but that doesn’t tell the full story. For example, it won’t display relationships between triggers and fields such as tickets, users, and organizations. So, once again, you have to read through all the relevant triggers to look for fields they mention that might have changed, and to just generally know what fields might have changed.
• As for keeping an eye on triggers that break, there’s no real answer to that today. Simply check back often, or schedule time to do periodic sweeps.

Going through all your triggers every time is probably not a viable option if you have hundreds or yes, thousands of them, which is the case for some businesses. That’s why so many teams are so heavily reliant on you, the administrator, having a hunch or remembering enough about how the system was built to know what broke. But if that fails, what do you do?

Well, I’d like to present another way.

Identify and fix broken triggers with Salto

Salto is a Zendesk management tool that fetches your whole Zendesk configuration into an environment where you can run searches and make tweaks. It reveals lots of useful information the Zendesk UI doesn’t, and it can detect and highlight broken Zendesk business rules. (If a rule references a field, and Salto can’t also find that field, it’ll alert you.)

That means you can use Salto to:

Find all broken business rules

Once you fetch your Zendesk account, you’ll see errors pop up in Salto’s Problems Panel. It’ll tell you which business rules (like triggers) reference a field or object that does not exist.

It’ll say (zendesk_support.<typeName>.instance.missing_<internalId>).

Click on each entry and you can follow it to a broken condition or action. (Alternatively, you can also do a text search for “.instance.missing_” to bring up all the instances where a field reference is missing.)

Understand if changing an object (like a field) will affect a rule

Because Salto understands the relationships between all the objects in your Zendesk instance, it can tell you things that only Zendesk itself knows, but isn’t built to reveal. For example, Salto can show you which objects are referenced by which rules.

In Salto, go to the Elements tab and search for the name of the object (business rule, fields, field options, views, whatever you want). Click on an object and click “Used by.” That’ll show you any other object that references this one.

So, if you or anyone on the team is unsure whether they can safely delete a field option, they can check here and see how important it is, and where it’s being used.
‍

Get notified when there’s a broken rule in your instance

Salto also has a useful “set an alert” function. You can set it to notify you if a trigger changes, and it’ll send you a message via email or Slack. If you get one of those notifications and go back to Salto, you’ll probably see that the trigger has a .instance.missing_ reference, and by now, you know what that means—that the related field disappeared or changed.
‍

All these features are available in Salto’s forever-free tier. Just create or log into your account, fetch your Zendesk instance, and start identifying and debugging broken triggers.

See your broken triggers and keep your references up to date

Let's recall that part of what makes Zendesk so appealing is its flexibility. Let’s hope it never changes that. But with DevOps-like tools such as Salto, you can implement a layer of observation and control that makes it a little more secure to develop in, and saves you time. And the free version can help you answer common questions, like “Where are my broken triggers?” and “Which fields are being referenced where?” so you spend less time debugging, and more time helping users offer excellent support.