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.
For information about creating and managing automations, see Streamlining workflow with time-based events and automations. For a list of default automations, The Support 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 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, like all business rules, must be smaller than 65kb.
About 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).
- 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).
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 processed. On jobs that are very large it may take several hours to work through all of the tickets that would have otherwise been acted upon that first hour.
To prevent unnecessary activity, automations do not run on accounts that haven't had anyone sign in within the last 14 days.
Understanding when automations 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.
- 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 the ticket is solved and the 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: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.
30 Comments
is there a way to change the hourly automations? i used have something like that in my previous CRM, that allowed me to run an automation every night about neglected cases (last update was 96 hours ago), and send an email to the assignee about it.
now it appears i can't do it on Zendesk since you run every hour. are there any plans to allow the users to modify the time?
I very much doubt ZD will be changing the hourly automation cycle simply because of the way automations work and the load this would then create. However do you really need these emails to only go out at night? If it's been 96 hours then would it matter if you sent the email during the day? You can specify how many hours since the last update in the automation.
Hi.. I've create automation with condition below, perhaps anyone can help me to find the root cause.
Ticket status: is On-Hold
Ticket: Hours since On-Hold (bussiness) is 24
Performs: Send Email to Requester
Ticket condition: Open -> On-Hold -> Open -> On-Hold
Quick look on the result, 24 hours calculation On-Hold is counting from the 1st On-Hold, while I need from the last On-Hold status.
Anyone can help me on this?
Thanks,
Hi, I have seen this also. The problem is in the way automations work. As noted in this document all the changes are combined together so if you have automations that change the status then change it back then the net effect is no change and hence no change will occur. If no change has occurred then the last changed date will not update.
I tried to be clever and use a trigger to change it back but that does not work either.
Hi Colin,
Thanks for your information, the status changed because of customer reply to my update which every time I send update to Customer, I set my ticket status to On-Hold. This is why the ticket become Open then On-Hold again.
I need inputs on how to set the best setup fro this automation.
Hi. So if a customer replies to a ticket that is on hold, you want to change the status back to being on hold? Correct? If so then a trigger may be better. Please confirm and I will help further. Thanks
Hi Colin,
It's the other way around.
If I sent an answer to Customer question, the ticket is set to "OnHold". This email also asking whether the information I sent is answering customer's question. After this step, it will have 2 possibilities:
1. Customer Replied: The ticket will back to "Open" again & if I need to answer again, it will goes to "OnHold" again.
2. No respond from Customer: This where I want automation work, from the last "OnHold", if 24Hours no respond from Requester, it will set to sent e-mail reminder that ticket will be closed in next 24Hours.
I hope you can help me out here :)
Thanks,
Ok, so this seems simple. Does this work for you?
Meet all of the following conditions:
Ticket: Status Is On-hold
Ticket: Hours since on-hold (calendar) Is 24
Perform these actions:
Notifications: Email user (requester)
Ticket: Add tags sent_warning
This will send the reminder after 24 hours. It will also set a tag so you can then add a second automation but this time set for 48 hours.
Meet all of the following conditions:
Ticket: Status Is On-hold
Ticket: Hours since on-hold (calendar) Is 48
Ticket: Tags Contains at least one of the following sent_warning
Perform these actions:
Ticket: Status Closed
Ticket: Remove tags sent_warning
How's that?
Hi Colin,
Thanks for the advise.
I've set the codition same like you,
Ticket: Status Is On-hold
Ticket: Hours since on-hold (calendar) Is 24
Perform these actions:
Notifications: Email user (requester)
Ticket: Add tags sent_warning
If condition like this:
Day-1. Ticket "Open"
Day-2. I reply, "OnHold"
Day-3. Customer Reply - "Open"
Day-4. I reply back, "On-Hold"
.
Will the automation calculate from "OnHold" in Day-4 or from Day-1?
Because previously, when I run a test, it was calculated from Day-1, causing ticket which On-Hold in Day 4 is also get reminder letter.
Regards,
It should be Day-4. If this is not the case then the reason will be in the ticket audit which unfortunately I will not be able to see.
@Jessie -- if you are listening -- if we get a domain and ticket number can you take a look at the audit for this ticket to see what actually happened.?
I noticed that this article says "Automations do not run or fire on closed tickets." Does this mean an automation set with the condition "Ticket: Hours since closed (business) is 2" is completely useless?
Step 3 in the final paragraph should be 12:10pm, not am.
Other than that, useful article.
Is there a way an automation could show a ticket listing? For instance, when you click "Preview match for the conditions above", can the automation show all the tickets above and beyond the preview?
Hey Jimmy -
I don't believe that there's a way to get the automation preview to list all tickets it would apply to, but we may be able to find another way to get at the information you're looking for. Could you give us more detail about what you're trying to accomplish?
My thinking would be this automation would be a subscription to a given filter of the query in the automation. In the case I was testing, I wanted to display/notify the assigned group a listing of unsolved tickets with a creation date of 30 days or older. It seems today the only option is to send a notification per ticket, which seems to be overkill. Does that make sense?
Hey Jimmy,
You wouldn't be able to set this up through an automation since, as you stated, automations fire on each ticket. One possible workaround would be to create a View and use the Hours since created and Status>Less than >Solved conditions to show a list of these tickets. You can then make this view accessible to all agents within a certain group if you'd like.
Additionally, once you've created this view you do have the option of exporting to a CSV file. You can then forward the email you receive to the desired users. I've attached our Views article for additional info.
Here's a sample view I've attached below:
I realize this workaround requires a bit more manual work but hopefully this gets you relatively close to what you're looking for.
Let me know if you have any other questions!
Same question as Landy Hite:
"I noticed that this article says "Automations do not run or fire on closed tickets." Does this mean an automation set with the condition "Ticket: Hours since closed (business) is 2" is completely useless?"
What is/was the rationale behind enabling:
Since I can't set up the simplest of business rules using any or both, it's not entirely clear why they're there in the first place, and what's their use case. How can we use them?
Thanks in advance for clarifying!
Hi Pedro -
That's correct, an automation set with "Ticket: Hours since closed (business) is 2" would not run. Automations do not run or fire on tickets in the "Closed" status.
There is a problem ticket in to the product team to remove the Closed status conditions as it is a known issue that these exist but do not do anything. They have not provided an ETA on that fix.
Hello, I am trying to set up automations as change the status of all open ticket to solved then close them after 12h of each phases, and I run 2 automations as in the attached files, but all the open tickets stay the same open status without change to solved or close as expected (its been 4 days since the automation is set up), did I do anything wrong?
Thank you.

Hey David,
If you're just trying to assign a ticket to a specific view then you shouldn't need to create an automation to accomplish this. If you navigate to Admin>Manage>Views there should be a condition for Ticket: Received at you can use. I would use that condition along with Status>Less than>Solved or something similar to see the required tickets.
Let me know if you continue to experience issues on your end.
Cheers!
Hi,
I was wondering if there is a way to check that an automation has sent an email to a specific user? I think I read somewhere that there was a log of all the emails that were sent and who they went to. I'm hoping to see that an email was sent, not necessarily the content of the email.
Thanks in advance,
Rich
Hey Rich,
You can view the events of the ticket to see what automation has fired as mentioned here: Viewing all events of a ticket
Let me know if you have any other questions for me!
Rich Cooley,
Brett nailed it. Also I suggest adding tags as part of your Automations so you can do quick searches as needed.
Sincerely,
Heather
Hi,
Can i trigger this automation manually. There is one automation configured which was wrong earlier. Due to which customer did not get the notification. I have corrected that, how do i make this automation trigger manually so that the customer gets the notification.
If no manual trigger, then please suggest me what to do?
One more thing, does this automation runs as soon as the condition satisfies on every hour or only once. if this has run again and the notification has not been sent to user, will it send?
Regards,
Waseem Khan
Hi Waseem,
Your best option is probably to make a clone of the current automation and leverage tags. You can tag the ticket that needs an update sent with a unique tag and update the cloned copy of the automation to look for that specific tag. Then you can use the "preview match" feature in the automation settings to ensure that the automation is matching to the ticket, or check if the conditions need to be further adjusted. You can deactivate the second automation after the notification has been taken care of.
Good afternoon,
Automation are installed and fired but I can not find them?
I do not see my fired automations in my ticket. Is there a possibility to show this? I would like to see whether my client had received my reminder so I can adjust my communication.
Kind regards,
Annelies
You could add an action that adds a new tag unique to your automation rule.
That way, when the automation runs, the new tag will be available for you to trigger or report from.
Hi Annelies,
To see all the triggers and automations that have fired on a ticket, check the event log:
https://support.zendesk.com/hc/en-us/articles/203691176-Viewing-all-events-of-a-ticket
Of course this will only tell you what has been sent out, but not whether your client actually received it (e.g. because of a spam filter).
HI Annelies Schueler -
You should be able to change "conversations" to "events" to see what action Zendesk took on the ticket.
Hope this helps!
According to the article, if I have some SLA for less than one hour, the automation may not be fired in time and how can I make sure the automation can be fired?
Please sign in to leave a comment.