About triggers and how they work

Note: On Essential, you have a limited selection of conditions and actions to choose from when creating or editing triggers.

Triggers are business rules you define to 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:

• Essential facts for triggers
• About triggers
• Understanding trigger conditions and actions
• 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.

Note: Each business rule must be less than 65kb.

Essential facts for triggers

We've distilled some essential facts for you about triggers. These are explained in greater detail in our documentation (see Triggers resources).

• Triggers are created from conditions and actions. Conditions set the qualifications needed for the trigger to fire and actions represent what will be performed when those qualifications are met.
• Triggers will run, or check the conditions, immediately after tickets are created or updated. 

• Triggers will only fire, or apply their actions, if the ticket meets the trigger's set conditions.

• Actions applied by one trigger can affect other triggers.

• Actions in one trigger can affect the actions in another.
• Triggers do not run or fire on tickets after they are closed. However, triggers can fire when a ticket is being set to closed.
• Triggers, like all business rules, must be smaller than 65k.

About triggers

Triggers can help you manage your workflow and improve your customer satisfaction by automatically performing actions whenever a ticket is created or updated with specified conditions.

Here are some uses for triggers:

• Notifying customers when you're out-of-office
• Sending customer satisfaction score follow-ups
• Routing your priority customers to a specialized support group automatically
• Notifying agents when a problem ticket has reached a certain number of incidents
• Adding and removing tags
• Automatically assign tickets by channel
• Escalating tickets
• Decreasing spam emails and automated responses

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 its 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.