In my previous article, we covered how to choose between Zendesk Triggers and Zendesk Automations when you need to automate ticket-based actions.

In this article, we’ll look at the key building blocks that go into creating Triggers and Automations, so you can confidently automate monotonous tasks and save your team time, energy and focus.

Challenge

Whether you’re building a Trigger or an Automation, both have the same key components. 

The hardest of these to get right is the section called “conditions”. Conditions are the rules which must be met in order for your designated actions to run.

Zendesk provides us with an array of options to set the exact conditions we desire. Although this is great for being able to build the rules we desire, it can also make it a bit hard to get used to initially..

Below, I’ll walk you through the key concepts that will unlock powerful customisation options for all of your automations by mastering the skill of building expert conditions.

‍

The “All” section

Zendesk offers us two sections within which to add our conditions, “ALL” and “ANY”.

‍

‍

Many Triggers and Automations will utilise both but, for now, we’re going to learn them one at a time.

If you have a Trigger or Automation in mind, and you know that you have just a few simple criteria that a Trigger must meet in order for the actions to fire, you can probably get away with using only the ALL section.

All conditions added to the ALL section must be true (i.e. the ticket must match all the criteria you set) in order for the actions to fire.

So, if you want a Trigger to fire if its status is New, it is submitted by an end-user, and the Priority is Urgent, you can do as below.

‍

‍

If any of these criteria are not true (for example, the Status is New, the role is end-user but the Priority is Low, Medium or High), then the actions you set will not happen.

The ALL section, then, is to be used for conditions which must always be met. But what if you have multiple conditions, and only need a minimum of one of those conditions to be met?

‍

The “ANY” Section

The ANY section works in conjunction with the ALL Section. This is the first point to note as Zendesk does not allow a Trigger or Automation to be saved if its ALL Section is empty.

So, whilst the ANY section works very differently to the ALL section (see below), it cannot be used on its own, unlike the ANY section. Your Triggers and Automations will always have either just its ALL section populated, or the ALL and ANY sections populated.

The ANY section is incredibly useful when you have one or more conditions, a minimum of only one of which needs to be true for the actions to fire. For example, you might want to create a trigger that acts on any ticket that has any chance of being associated with your Sales team.

To give you the best chance of “catching” these tickets, it’s useful to stipulate multiple conditions which could indicate the presence of a Sales ticket. We don’t want to use the ALL section, however, as there’s a high chance that not all of these conditions will be met simultaneously. We’re just looking for at least one of these Sales related conditions to be met in order for our Trigger to fire.

Let’s look at this example in practice:

‍

‍

First of all, we see that we have a condition in the ALL section, so this condition must always be true in order for the Trigger or Automation to proceed.

Within the ANY section, we have unique conditions. In order for the Trigger or Automation to fire, at least one of them must be true. If one, two or three of these ANY conditions are met, along with the condition in the ALL section, the actions will fire. If none of the ANY conditions are met, the actions will not happen.

‍

A Further Clarification

Personally, I think the Zendesk UI isn’t quite as clear as it could be here, in terms of explaining the relationship between the ALL and ANY sections.

To help, I have annotated the UI below, to highlight how Zendesk processes your conditions.

‍

‍

In mathematics and spreadsheets, we are used to using brackets (parentheses) to delineate phrases and logic. We can use the same format to highlight the logic of Zendesk’s Triggers and Automations conditions:

Imaging we have conditions A1 and A2 in the ALL section, and conditions B1 and B2 in the ANY section, then Zendesk’s logic is the same as the below expression, with “AND” replacing “ALL” and “OR” replacing “ANY”

‍

‍

As you can see here, there are really two “AND” (e.g. ALL) operators at work, which is why it might be a bit confusing that Zendesk doesn’t show the relationship between the displayed ALL and ANY sections.

To illustrate it differently, here’s another way of looking at it which might be more intuitive for some people:

‍

‍

Limitations of ANY conditions

In our previous example, we input three different conditions into our ANY section, all of which were working towards the same purpose of identifying Sales-related tickets. But what if we had another grouping of conditions that we wanted to add, for a secondary purpose? For example, a ticket that was likely to be associated with Sales, but also came from either the Chat or Twitter channels.

We might try and create something like this:

‍

‍

Beware though, this would badly misfire! Remember what we learned earlier: the ANY section only requires a minimum of one ANY condition to be true in order for the ANY section to move on to firing the actions.

So in the example above, a ticket could come via Twitter but not have any of those Sales conditions and the Trigger or Automation would fire, so long as its ALL conditions were also met. Similarly, a ticket could be in the Sales group but not come via Chat or Twitter, and the ANY section would still return a positive result.

Unfortunately Zendesk doesn’t allow us to separate out our groups of ANY conditions, the equivalent of adding more brackets in a spreadsheet formula. Thus we need to create separate Triggers/Automations for each distinct purpose and not get carried away in one set of conditions!

Summary

To conclude, we learned how to create straightforward conditions using the ALL conditions. We also extensively covered the relationship between ALL and ANY conditions, including the fact that every Trigger/Automation needs an ALL section. Finally, we looked more closely at the ANY section, including how powerful it can be but also how things can quickly go awry if you get carried away.

Hopefully, this knowledge will set you on your way to building the perfect conditions to automate hundreds of actions every day.