Learn how to order your triggers

If you're reading this in our web widget, consider expanding the article for a better reading experience.

Whether you are starting from scratch or working with an established environment, the order of your triggers is important for a well designed Zendesk account.

There is no perfect order for triggers that can fit every account, but we suggest these guidelines to create better structure, providing an environment where your triggers fire at the right time and situation.

‣ Use dividers in your trigger list

Dividers help show the role of the triggers in your list. In this example, we have divided our trigger list into 3 categories:

• set
• assign
• notify

Each category explains the high-level function of the triggers and focus on the trigger actions.

Therefore, in the set category, we find only triggers that set data as final action, in the assign category, we find triggers that assign tickets to users, and so forth.

This way of visually separating triggers helps you locate a specific trigger in a list, and makes debugging you triggers easier.

Read How do I organise the triggers of my account? for detailed instructions.

‣ Adopt a naming convention 

Naming conventions help provide information at a glance. This is important when multiple users are creating triggers. You can think about it as a short instruction manual on how to use the trigger.

The trigger naming conventions we suggest are:

1. Emoji
2. Department
3. Category
4. Action
5. Owner
6. Title
7. Number

Emoji

Emojis can visually represent meaning. Use this feature to highlight the key trigger action. Above, we used the emoji for outbound emails in a trigger that sends out a notification via email to customers.

Department

Above, we used the department 'Customer Service' to make sure the trigger is not confused with some other triggers with the same function.

Category

This is the part that locates the trigger function in your organisation. Above, we use 'Support', but it could be Sales, Customer Success, etc.

Action

The action performed by the trigger. In the example, notify customers of a received request.

Owner

Who has created or manages the trigger. This is useful when you need to contact the owner of a trigger for further explanation.

Title

The title of the trigger.

Number

Sometimes you have triggers that act as a block of actions, multiple triggers fire one after the other. Using numbers helps to understand the workflow and facilitate debugging potential issues.

‣ Break down complex workflows in several triggers 

When dealing with complex workflows, it might not be possible to condense all the trigger conditions and actions in a single trigger.

When that's the case, breaking down the workflow into several triggers can be the solution. For example, you can have 4 triggers:

1. emoji/department/category/action[set-tag1]/owner/title/1/4
2. emoji/department/category/action[set-tag2]/owner/title/2/4
3. emoji/department/category/action[set-tag3/owner/title/3/4
4. emoji/department/category/action[notify-group1]/owner/title/4/4

The first trigger sets some data, for example a tag, that causes the second trigger to fire. The second trigger sets another tag that causes the third trigger to fire, so on and so forth until the 4th trigger fires to notify a group, and the workflow ends.

Advantages of this design:

• Debugging: the first trigger firing acts as leader, in that if the following trigger in the sequence does not fire, the issue is likely in the trigger leader.
• Clarity: the actions are likely smaller, clearer in their intent, and easier to understand.
• Numbers: using numbers in the naming convention help visualize and organize these small, targeted use cases.

‣ Understand the sequence in which the triggers fire 

Triggers fire as a consequence of a ticket update. This fact should always be kept in mind when creating or debugging any triggers issue.

When a ticket is updated, the system checks triggers for a match in a sequential order, from the top of your trigger list, to the bottom.

When a match is found, the system checks the triggers once again from the top of the list, this time skipping those triggers that have already fired.

This behaviour means that:

• A ticket could loop through the trigger list several times for a single ticket update.
• A trigger can be checked several times during a cycle, but never fire more than once on the same ticket update, because the trigger is not checked again after it fires.
• A trigger will not fire if it's not a match.

It's important to consider such implications prior to decide the order of your triggers.

For more details and a visual representation of this process, see About triggers and how do they work