Automations are similar to triggers because both define conditions and actions that modify ticket properties and optionally send email notifications to customers and agents. Where they differ is that automations execute when a time event occurs after a ticket property was set or updated, rather than immediately after a ticket is created or updated.
All automations run once every hour on all non-closed tickets. They execute, or fire, on all tickets where conditions are met.
On Essential you have one default automation. On Team, Professional, and Enterprise you have a set of predefined default automations and you can create custom automations.
For information about creating and managing automations, see Streamlining workflow with time-based events and automations. For a list of default automations, About Zendesk default automations.
Essential facts for automations
Automations are time-based; they take action when a time-event occurs, not immediately after a ticket is created or updated.
Automations run every hour, but not necessarily top-of-the-hour; they will start at some point during the hour.
Your automations will always start running at the same time every hour.
Automations do not take action on a ticket until all automations are checked; all automations see the ticket in the same state when they run.
Automations do not run or fire on closed tickets.
An automation must contain a condition that is true only once or an action that nullifies at least one of the conditions; otherwise, the automation will run in an endless loop.
Automations help you manage your workflow and, potentially, improve performance and customer satisfaction by alerting you to tickets that remain unresolved and need to be escalated (for example).
- Notifying agents when an assigned ticket remains unresolved for x number of hours
- Notifying agent groups when a new ticket remains unassigned for x number of hours
- Notifying the assigned agent after x number of hours when a pending ticket has been updated by the requester
- Closing tickets x number of days after they have been set to solved
- Finding "abandoned" tickets that haven't been updated for a certain number of days
- Sending a delayed notification for ticket comments added outside of your business hours (using a trigger with an automation; see Setting up a time delayed comment)
- Sending an SMS text message when an urgent ticket has been unattended for more than 48 hours (using a target with an automation; see Using targets in automations and triggers)
Zendesk provides an automation that demonstrates one of these common uses:
This automation closes tickets 96 hours after they have been solved (96 hours is a support best practice for the minimum amount of time a ticket should remain in the solved state before it is closed). When the automation runs, any tickets that meet these criteria are closed. The close action looks like this:
Once a ticket is closed, it can't be modified anymore and automations no longer affect it.
This example also illustrates an important rule of automations: an automation must contain an action that cancels a condition. The ‘Status equals Solved’ condition is canceled by the ‘Status equals Closed’ action. If there were no canceling action, the automation would continue to fire in an endless loop because the status would remain solved (not closed) and continue to meet the condition criteria.
Ensuring your automation only runs once
Automations check every hour to see if their conditions are met. So an automation must include one of the following:
- an action that nullifies at least one of the conditions, or
- a condition than can be true only once
If there is no nullifying action or true-only-once condition, the unmodified conditions will continue to be met and the automation will continue to fire in an endless loop.
An example of a condition that is commonly nullified is a "ticket priority" condition. A ticket priority condition is usually paired with a "hours since created" condition. For example, if the ticket priority is Normal (Ticket: Priority > Is > Normal), the condition is nullified by including an action that changes the priority to High (Ticket: Priority > High) or some other priority.
An example of a condition that can only be true once is the "hours since open is" condition. This condition doesn't require a nullifying action. For example, if the hours since the ticket is open is 4 hours (Ticket: Hours since created > Is > 4), then the condition will only be true on one check. On the next check, the hours since open will be 5, and the condition will be false.
An easy way to cancel a condition is to add a tag. The automation would check for a tag and, if not present, the automation would add the tag to the ticket and perform any actions (such as, sending a notification). If the tag is present on the ticket, the automation will not perform the action again.
Understanding when automations run
Your automations run every hour, but that does not necessarily mean top-of-the-hour. Your automations will start running at some point during the hour, maybe five minutes after the hour or thirty-eight minutes after the hour, for example. Your automations will always start at the same time each hour.
Although your automations start at the same time each hour, they might not fire until much later. The entire time it takes your automations to run and execute depends on how many automations and tickets there are to process. Automations run again one hour after the start time (not one hour after they finish running).
Understanding when automations fire
Automations run in order every hour and fire on tickets where conditions are met. But automations do not fire—that is, take action on a ticket—until all automations are checked. That means all automations see the ticket in the same state.
If conditions are met for an automation, the actions of the automation are noted, then all of the actions are applied to the ticket at the same time. The ticket doesn't change as automations run, so the actions of one automation cannot affect another automation in the same hour.
- Automation #1: If status is Open greater than 48 hours, notify Assignee.
- Automation #2: If status is Open greater than 48 hours, change priority to High.
- Automation #3: If priority is High and hours since update by Assignee is greater than 4 hours, notify Escalation group.
When automations run they see the ticket in the same state. So, if you have a ticket that has been pending for 48 hours, when automations run in the 49th hour, Automations #1 and #2 are met and will fire. Automation #3 is not met until Automation #2 updates the ticket, so it will not fire until the next hour.
As mentioned previously, automations, unlike triggers, do not execute an action immediately after a ticket satisfies the conditions. And automations do not execute exactly one hour after conditions are met. For automations, ticket updates depend on when your automations run each hour. When an automation runs it will either update a ticket or start the clock for a time-based condition ("Hours since update" for example).
Let's consider an example where the action will happen when the automation runs. Suppose a ticket update at 10:15am satisfies the conditions for an automation to send an email notification. If your automations run at 11:10, then the notification will not be sent until 55 minutes after the conditions are met. If your automations, however, run at 10:20, then the notification will be sent 5 minutes after the conditions are met.
Now let's look at example with a time-based "Hours since" condition. Time-based conditions have to be satisfied within a window of time or after a minimum amount of time has passed. The first time an automation runs after an event occurs counts as "zero" hours since that event happened (because it's less than one whole hour).
- If your automations run at 10:10am, the ticket has been solved for only 55 minutes and the automation will not fire.
- Automations run again at 11:10am, the ticket has been solved 1 hour and 55 minutes, which the automation counts as one hour (because it is less than two hours).
- Automations run again at 12:10am, the ticket has been solved 2 hours and 55 minutes, which the automation counts as two hours. This means the condition is met and the automation will fire and update the ticket.