Triggers: The importance of the 'Ticket is' condition

One of the most important considerations when building triggers (or other business rules) is to be as specific as possible when creating conditions. You want to apply the trigger only to relevant tickets. A good example of this, and a common mistake, is forgetting to set the trigger's scope using the Ticket is condition. This condition has two values: Created and Updated.

The use of this one condition can make a significant difference in how many tickets are processed each time triggers are run.

For example, if you're creating a trigger that routes tickets based on some criteria as they are received in your Zendesk, you want to include the Ticket is... Created condition to the trigger. Doing so ensures that this trigger only applies to tickets when they are first created and not applied to those same tickets when they are later updated. Tickets are only created once of course.

Here's an example of a trigger that uses the Ticket is...Created condition and assigns newly created tickets containing specific tags to the Level 2 support group.

This trigger runs once for every newly created ticket that contains either of those tags.

What would happen if we didn't set the Ticket is...Created condition? Each time a ticket containing either of those tags is created or updated, it would be assigned to the Level 2 Support group (because all of your triggers run each time a ticket is created or updated and there are no conditions preventing the group assignment from reoccurring). Of course, that's what we wanted initially but what if we had subsequently assigned the ticket to different group? The ticket may be reassigned to the Level 2 Support group each time it is updated.

Note: We say 'may' in the sentence above because what exactly happens to tickets when they are created and updated is based on your triggers and the order of those triggers. For example, one trigger may set the group assignment and another trigger farther down in your list of triggers may assign the ticket to a different group.

If you do want to apply actions to tickets, based on some criteria, each time they are updated you use the Ticket is... Updated condition.

The most common example of when to use this condition is when you want to send notifications to the requester. To see an example of this, take a look at one of the default notification triggers in your Zendesk account: the Notify requester of comment update trigger, for example. You want those actions to occur each time a new public comment is added.

The default behavior of a trigger that contains the Ticket is...Updated condition is that the trigger's actions will be repeated each time the ticket is updated as long as the trigger's conditions remain true.

This means that you can also use the Ticket is...Updated condition and apply the trigger's actions only once to a ticket. For example, perhaps we wanted to make our bank customer tickets high priority. We only want that to happen once. To do that, in addition to the Ticket is...Updated condition we also add a condition that checks to see if the ticket's priority has already been set to high. In other words, if the ticket doesn't meet the criteria defined by the conditions, then the trigger is not applied to the ticket.

In this trigger, we're setting the priority of any tickets for bank customers (we know they're bank customers because of the tags we've added) to high priority the first time the ticket is updated. But first, we check to see if the ticket's priority is already set to high, which would indicate that the trigger has already run on the ticket. If it has, the ticket is not updated.