About triggers and how they work

Note: On Essential you have a set of predefined default triggers. On Team, Professional, and Enterprise, you have a set of predefined default triggers and you can create custom triggers.

Triggers are business rules you define that run immediately after tickets are created or updated. For example, a trigger can be used to notify the customer when a ticket has been opened. Another can be created to then notify the customer when the ticket is solved.

This article describes the building blocks that make triggers and explains how they run.

This article contains the following sections:

• Understanding trigger conditions and action
• Understanding when triggers run and fire

For information about creating and using triggers, see Streamlining workflow with ticket updates and triggers. For a list of default triggers, see About the Zendesk Support default triggers.

Understanding trigger conditions and actions

Triggers contain conditions and actions. You combine these to create ‘if’ and ‘then’ statements (if the ticket contains a certain set of conditions then the actions make the desired updates to the ticket and optionally notify the requester or the support staff). You build condition and action statements using ticket properties, field operators, and the ticket property values.

There are two types of conditions – all conditions and any conditions. The all conditions, as you've probably already figured out, must all be true. If any of the condition statements fail (are not true), the trigger will not act on the ticket.

Additionally at least one of the any conditions must also be true. For example, you might want a trigger to act only on tickets that are submitted from a list of specific email addresses, as in this example:

If either of these conditions is true, the trigger will fire. If you use only one condition in the any section, it will behave like an all condition and therefore must be true for the trigger to fire.

Action statements follow the same format, but rather than testing for conditions to be true or not, actions set ticket properties and send email notifications, as in this example:

Understanding when triggers run and fire

Every time a ticket is created or updated, all of your triggers run in a cycle against that ticket. A trigger will fire and update the ticket if it's conditions are met during the cycle. A cycle is the entire process of a ticket being checked against all your triggers.

If a trigger updates a ticket during the cycle, the cycle starts over. All the triggers run again, except any triggers that have already fired and updated the ticket. This means a ticket could loop through the trigger list several times before all of the triggers have either updated the ticket or been skipped because conditions were not met. (See the image below.)

So a trigger might run (that is, be checked) several times during a cycle, but it will never fire (that is, take action) more than once in the same cycle because the trigger is not checked again after it fires. And a trigger will not fire at all during the cycle if the conditions are not met.

Because triggers start over when a trigger fires, triggers can affect each other. A ticket update by one trigger might cause another trigger, where conditions were not previously met, to be true and fire. So you might want to think about the order of triggers, as an action in one trigger might change a ticket property that was changed by another trigger.