About triggers and how they work

Triggers are business rules you define that run immediately after a ticket is created or updated and automatically perform actions if specified conditions are met.

Here are some uses for triggers:

• Notifying customers when you're out-of-office
• Sending customer satisfaction score follow-ups
• Routing your priority customers into a specialized support group
• Adding and removing tags
• Assigning tickets by channel
• Escalating tickets

This article describes the building blocks that make triggers and explains how they run. You can also watch this video:

What's Good: Business Rules (1:38)

This article contains the following sections:

• Essential facts for triggers
• Understanding trigger conditions and actions
• Understanding when triggers run and fire

For information about creating triggers, see Streamlining workflow with ticket updates and triggers.

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, except when the ticket is closed by the system after 28 days.
• Triggers, like all business rules, must be smaller than 65kb.
• To help you manage large numbers of triggers, triggers can be organized into categories.

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 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 a single condition statement in the all conditions section fails (is 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 in the order the triggers are listed. 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 cycle starts over when a trigger fires, triggers can affect one another. A ticket update by one trigger might cause another trigger, where conditions were not previously met, to be true and fire. So the order of your triggers is very important, as an action in one trigger might change a ticket property that was changed by another trigger.