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 an 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.
For information about creating and managing automations, see Creating and managing automations for time-based events . For a list of standard automations, see About the standard Support automations.
Essential facts for automations
We've distilled some essential facts for you about automations. These are explained in greater detail in this article.
- 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.
- Automations can fire on a maximum of 1,000 tickets per hour.
- Automations do not run or fire on closed tickets.
- Each ticket can be updated a maximum of 100 times by automations.
- An automation must contain a condition that is true only once or an action that nullifies at least one of the conditions.
- All active automations must be unique. They can have some overlapping conditions, but they can't be identical.
- Automations, like all business rules, must be smaller than 65kb.
- You can have a maximum of 500 active automations at a time.
- On non-Enterprise plans, automations are visible to agents, including light agents and contributors, but can only be edited by admins. On Enterprise plans, automations are visible only to agents in custom roles with permission to manage automations.
Examples for using automations
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).
Here are some uses for automations:
- 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 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.
However, it’s important to be thoughtful when using an “hours since...is” condition. Because of the slight variation of run times for automations in any given hour, it's unlikely but possible for an “is” condition to never evaluate to true. This situation is more likely for larger accounts, or accounts with many automations. For details, see Using the “Hours since” condition in automations.
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.
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 at some point during the subsequent hour.
Each automation can act on a maximum of 1,000 tickets each hour. If there are more than 1,000 tickets where conditions are met for an automation, 1,000 tickets will be processed in that hour, and the remaining tickets will be processed during the next hour, if conditions are still met, or the hour after that, until all tickets are checked. On jobs that are very large it may take many hours to work through all of the tickets that meet the conditions of that automation.
An extended automation cycle increases the chances for agents to be making routine ticket updates at the same time as automations are running. To prevent ticket update collisions, Zendesk automations double-check the state of the ticket at the time of the update, instead of just acting based on the state of the ticket when the automation cycle started.
To prevent unnecessary activity, automations do not run on accounts that haven't had anyone sign in within the last 14 days.
Understanding when automation actions fire
Automations run in order every hour and fire on tickets where conditions are met. Each automation fires—that is, takes action on a ticket—when the automation runs and conditions are met. That means the ticket is being updated each time an automation fires during the cycle, so not all automations see the ticket in the same state. The actions of one automation can affect another automation in the same hour.
- Automation #1: If status is Pending greater than 48 hours, notify Assignee.
- Automation #2: If status is Pending greater than 48 hours, change priority to High.
- Automation #3: If priority is High, notify Escalation group.
Automations run and fire (if conditions are met) in order. So, if you have a ticket that has been pending for 48 hours, when automations run in the 49th hour, Automation #1 runs and fires, then #2 runs and fires. After Automation #2 fires, the ticket is updated to High priority. This means that when Automation #3 runs, the condition is met, so Automation #3 will fire.
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.
- 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.
-
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). Suppose
you have an automation that performs an action two hours
after a ticket is solved and a ticket is solved at 9:15am.
Here's what will happen:
- 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:10pm, 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.
75 comments
Hannah Lucid
Hi Brandon (729),

Here are some screenshots of what is currently setup. The first image shows the automation that set the ticket in a Solved status. The second image shows the automation setup. It seems straight forward to me, so I'm not sure what could be causing this. Any help is appreciated.
0
Brandon (729)
Hey Hannah Lucid -
To quote Maui from Moana... "I see what's happening here."
A ticket can't be in two groups at once, so at least one of those "Any" conditions has to be true.
Moving those "Any" conditions up to "All" should set you straight.
Current: "If [Status is Pending AND Greater Than 24 BH] AND [Group Is Not A OR Group Is Not B], Close The Ticket" >> If in Group A, Not In Group B, so "Group Is Not B" is Satisfied.
Desired: "If [Status is Pending AND Greater Than 24 BH AND Group Is Not A AND Group Is Not B], Close The Ticket" >> If in Group A Or B, "All" Conditions not Satisfied.
Cheers,
Brandon
0
Hannah Lucid
Brandon (729) this may sound like a stupid question, but do Automations consider ALL and ANY conditions differently from Triggers then?
When using a Trigger, if you would place these groups in the ANY condition section so it looks for any of those values to be true, because a ticket couldn't have ALL of those condition be true.
Example:
ALL condition:
Ticket | is | Update
Form | is | XXX Form
ANY condition:
Group | is not | 1234 Group
Group | is not | 7890 Group
Does that make sense or have I thought myself into a black hole of nonsense? Also, thank you so much! That seems to be the resolution I needed for those automations.
0
Brandon (729)
Hey Hannah Lucid -
Rule #1 - There are no stupid questions!
Automations & Triggers respond to conditions the same way. When evaluating business rules, Zendesk plays by the following rules: Every "ALL" statement must return TRUE and at least one of the "ANY" statements must return TRUE.
Let's say you have three Groups: 123, 456, 789.
Conditions:
Group is 123
Group is 456
You couldn't make these "All" conditions, because the ticket can't occupy two groups at the same time. However, since the ticket could occupy Group 789, you could make the following conditions "all": Group is not 123; Group is not 456 (both of these statements are also true).
Under the "Any" conditions, if you have the same conditions
Group is 123
Group is 456
That rule will only execute when the ticket is in Group 123 OR Group 456 and not when it is in Group 789 (since none of the "any" conditions are met. Here's where it gets tricky.
Group is not 123
Group is not 456
These groups as "any" conditions present a challenge, because if the ticket is in Group 456 (or Group 789), the "Group is not 123." Therefore, at least one of the "any" conditions has returned True and the rule executes.
In your scenario above, tickets updated on form XXX will meet the "All" criteria, and regardless of what group they are in, at least one of the two "Any" conditions will always be true, since the ticket can't occupy two groups at the same time. The fact that it worked sometimes was probably purely coincidental (perhaps the ticket was on a different form or in a non-conditioned group, so it gave the appearance of working - but if you were to stress test it against the conditioned groups, it would probably execute undesirably).
To solve for a more complex version of this, you could deploy two Triggers with the same "all" conditions but different, non-conflicting "any" conditions. If it's any consolation, it took me several rounds of smashing the keyboard to wrap my brain around this concept the first time!
Brandon
2
Hannah Lucid
Brandon (729)
To quote Krunk from The Emperor's New Groove "OH YEAH. It's all coming together".
3
Jennifer Rowe
I love this whole exchange. Thanks for helping, with that explanation, Brandon (729). And glad you got it Hannah Lucid!
0
Tammas
Can I have an automation run based on a closed ticket + X amount of time, but have that automation do a thing to the Requester of the ticket rather than the closed ticket itself?
Basically, I only want to send a CES survey to users every 6 months. So we set a profile checkbox once we send a survey and after 6 months i want to unset that checkbox so we can re-survey them again.
Will this work if automations wont run against a closed ticket?
0
Noly Maron Unson
Hi Edrolo,
Unfortunately, it is an inborn rule that Closed status tickets cannot be updated and this also includes changes made by automation or other business rules even if the actions indicated in them do not make any change to the ticket and is targeting a requester field.
0
Rob Geller
Can automations be used to send reminder emails to clients?
i.e. We send a client a quote on Day 1.
If client hasn't responded by Day 3 (or any number of days we select), we would like an email to automatically be sent to the client as follow up.
0
Jhan
0
Lars Schweikardt
Hi there,
I am curious about how to prevent a trigger gets executed when an automation updates a ticket. In the events of a ticket an automation updates the ticket with the "system" user, but it is not possible to no trigger based on a condition such as current user is not "system". Is there a way to exclude automation updates from a trigger?
0
Tony
you should be able to prevent a trigger from running when an automation updates the ticket, by using the condition "Ticket updated via" then "is not" then "automation" on the trigger.
Check this article to know more.
Best,
0
Ashleigh Bulmer
I have set up an automation with the action:
Notification Target > Create internal comment on ticket.
On the ticket I can see this automation ran in the events tab. But no internal note is present on the ticket. How do I get this to work?
Context: I have an automation that runs following a macro that emails the customer. This is successful and working. However as the action sends the email external to the ticket I want that response to still appear on the ticket somewhere so that engineer's don't have to go into the events tab to see it's been done.
0
Kévin Arnoult
👋 we got impacted by this limit with automations: “Each ticket can be updated a maximum of 100 times by automations”
When that happens, a system update is added to the ticket as a note: “The maximum number of ticket updates that can be made by automations has been exceeded”
But that note is not searchable, and we haven't found a way to identify all tickets that could be impacted outside of leveraging the ticket audit API endpoint, which is not ideal.
Q1. Is there any way to be notified or to easily see all tickets that would be impacted?
Q2. Looking into this doc, I realize that there's another limit that we'd want to monitor: “Automations can fire on a maximum of 1,000 tickets per hour”
Same thing here, is there a way to get access to those automations that have reached that limit?
0
Brandon (729)
Hey Kévin Arnoult -
Sorry to hear you're having difficulty. You could potentially sniff for that note with a Trigger that adds a tag. There might also be an option to consolidate some of your automations.
I'm also sending this over to Amer at Qvasa to see if this is something they might be able to extract. Hope this helps!
Brandon
0