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 automationsrunonce every hour on all non-closed tickets. They execute, orfire, on all tickets where conditions are met.
For information about creating and managing automations, seeCreating and managing automations for time-based events. 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 startat some pointduring the 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.
- Automations, like all business rules, must be smaller than 65kb.
- All active automations must be unique. They can have some overlapping conditions, but they can't be identical.
- You can have a maximum of 500 active automations at a time.
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 an SMS text message when an urgent ticket has been unattended for more than 48 hours (using a target with an automation; seeUsing 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, seeUsing 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, ifnotpresent, the automation would add the tag to the ticket and perform any actions (such as, sending a notification). If the tagispresent 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 runningat some pointduring 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 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 automationcanaffect 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 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.
- 自动化在11:10am再次运行,票已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.
56 Comments
Robert Houston,
That is so strange!! Can you pull like 3 tickets in pending status that stage 1 should have fired off on and look at all the tags on them? I am wondering if this ran before on those tickets and you might need to reset the workflow by clearing the related tags.
HeyRobert Houston-
I'm going to have the Zendesk Support team look at this more closely for you. I feel like we're really close, but they will be better equipped to handle your request. Keep us posted!
Brandon
Heather RommelBrandon Tidd
Like magic some have actually run. I have no idea why except that I tried changing hours since pending away from business and to calendar. This shouldn't be the reason its fixed because we need the system to respond via business days and technically if business hours is 72 that would actually equate to 9 days. However, the problem with regular calendar hours is, or should be obvious, weekends and holidays will conflict with the pending automation or require an additional step to ensure those events are accounted for. Something that I can only assumed is also assumed for when using business hours instead of calendar hours since we can actually put in a business hours schedule.
I hope this helps you figure out how to best help me. I wouldn't also mind a better tag system. If I look at my tags its a cloud. Its not user friendly or really all that helpful. I want to be able to manage them but that is going to be my next area that I deep dive. Thanks again and I hope we can resolve my issue soon.
We want to add an automation that triggers an email to be sent to a specific inbox when a new ticket is received. I need that email tonotinclude any ticket details except the placeholders I select (ticket ID and ticket link). When I created this automation, the email I received included ticket details like the requester, Ccs, and the ticket attachments. Is it possible to not include this information?
HeyAmanda Graham-
I think what you'll want here instead is to utilizeExternal Targets.
This should allow for a more customized notification experience.
Hope this helps!
Brandon
That's exactly what I was looking for. Thank you,Brandon Tidd!
Brandon Tiddexcellent feedback so far. My question relates to schedules so I can use business hours in my automations.
假设有2 +安排我的公司,如何做do I know which schedule is being used by the automation to calculate business hours?
If you are on an Enterprise plan and have multiple schedules, triggers, SLA policies, views, and automations based on business hours will use the schedule applied to the ticket. W hen you create multiple schedules, the first schedule that you create, and the one that appears first in your list of schedules, is always yourdefaultschedule. Your default schedule is used for all tickets, unless you set up a trigger to apply a specific schedule to specific tickets.
I hope that helps clarify!
Hello Team,
I want to alert my support team when the "urgent" ticket has not been responded to within an hour (should send a reminder email to the team). I have tried the below but I still don't get any email reminder after a new urgent ticket has been created.
1. I could save the config below, but not working.. Plus, when clicking in "Preview match for the conditions above" for testing, it does not sort the ticket as expected..
2. Changed it to the "Hours since created LESS THAN" . I could see the sorted tickets as expected, but I could not save the config with the below error - which I assume the condition should be nullified.
3. I referred to the below article that recommends adding one more condition (tag) to make it nullified. I could save the config without any error but still nobody in the support team has not got the reminder email...
https://support.zendesk.com/hc/en-us/articles/4408886561050-What-does-the-Automation-could-not-be-updated-as-error-message-mean-
Can anybody please give me advice? I even tried a trigger.. (none of the tries did not work..)
Thank you.
HiJabin Choi-
Your logic seems correct in the 3rd version... the challenge here is that automations only run once per hour, and not consistently at the top of the hour. As it's written, this automation will scan for any new tickets that have been new for less than an hour at the time the automation runs. The problem is that if the automation runs 65 minutes after the ticket is created, it will miss the alert.
If you remove the time condition all together, the automation will pick up and notify on the ticket anywhere from 1 minute > ~59 minutes after the ticket is created (scenario A). If you change the condition to greater than 1, the automation will pick up and notify on the ticket anywhere from 61 minutes > ~119 minutes after the ticket is created (scenario B).
Let's say you have a ticket that was created at 12:15 and you want to send a notification around 1:15 if that ticket is still new. If the automations run at 12:10, 1:05 and 2:20, Scenario A would notify you at 50 minutes and Scenario B would notify you at 125 minutes.
The other thing you could do is create a view for tickets that are urgent, new and more than an hour old.
Hope this helps!
Brandon
HelloBrandon Tidd,
Thanks for the reply.
I have created a new urgent ticket for testing with the third config.
机票没有标签时称为“紧急”created.
After 0~1 hours, I was able to see the new tag "urgent" has been created.
This is really weird because it seems that one of the actions (Ticket: Add tags) works fine but the other (Notifications: Email User) does not.
I believe all actions I defined should work together, shouldn't it?
Do you have any ideas?
HiJabin Choi-
I believe this issue is that a new ticket is most likely unassigned, so emailing the assignee won't be applicable here. You'll either need to email the group the ticket is assigned to or have a trigger assign the ticket, thus enabling the assignee notification.
Brandon
What methods do people use to test automations?
I am finding myself making tiny corrections and then waiting an hour. Hoping there is a better way.
Hi Jonathan,
All automation runs once every hour and does not execute an action immediately after a ticket satisfies the conditions. As a workaround, you could copy your automation conditions (excluding the time-based conditions) into a test trigger and set the trigger's conditions so that it only fires for your test tickets.
For example, Meets ALL of the following conditions:
Ticket > Is > Updated/Created
Ticket:Tag > Contains at least one of the following > test_tag
Hope that helps!
Can I set an automation to auto-close tickets via channel - Chat at the end of each month.
我们都离开live chat tickets private but find them very useful. We have the option to make it a public ticket, and that's great. I have an automation setup to close tickets that are not relevant to my team.
What I am hoping to do is close all tickets via Channel Chat - at the end of each month, this way the tickets we see open at any given time are chats that came in within the month we are in at that time. At the end of that month, the tickets auto close, and the next month's chat tickets are the only open chat tickets visible until the next month ends...possible?
Your use case is not natively possible. It's due to the reason that there's no existing condition that will immediately check the day for the end of each month.
What you can do perhaps is to create a Date custom field. Then create a trigger that will set the date to the end of each month for every created ticket from the Chat Channel. Finally, you can then use that same custom field in your automations to close the tickets when the date is reached.
Please do take note that this process will force you to manually modify the triggers and automations each corresponding month.
I had a question regarding automations. I am trying to set something up where the agents CC'd on a ticket with get notified when the ticket has been open for 24 hours. However, the only option I am seeing is to email requestor and CC. Is there a work around where only the CC will be emailed and notified of the 24 hr breach?
Currently, there's no CCs only action in Automations and Triggers that I can think of. Closest thing that comes to mind areNotifying External Email Addresses.
It's an officially supported feature, but kinda grey area since it'll require some custom code. I hope this helps!
Hi There,
I was wondering if there is a way to make sure that Automations only run once per day for a specific user. We are sending out CSAT forms for each time that a user submits a ticket, but some users end up sending in up to 10 tickets in a day, is there a way to limit so that the CSAT is only sent once?
Finn
Hello Finn, thank you for your question!
Unfortunately, at this point, Automations as well as Triggers are not able to check conditions based on the number of tickets that a user has requested.
与此同时,CSAT调查是为了磨破k once per ticket, and if active, they will be sent to all tickets, unless ruled out by the Trigger's or Automation's conditions, but as I mentioned, these conditions are currently not capable of checking if a user already has a set number of tickets for the day (or any time frame, for that matter), or if it already has received a CSAT survey on another ticket.
But this is a good suggestion to have. I can recommend that you create afeedback Post in our Communityrequesting this feature. You can explain your use case and the more traction this post gets, the more chances there are for our Development team to consider implementing this in the future.
I hope this was helpful!
With the addition of adding in more variations to increments on the time based automations (15, 30, hr, etc), is there a plan to increase how often an automation runs? If we have something that needs actioned in less than 15 minutes, it wouldn't run for an hour which would interfere with workflows.
Can one *not* use a checkbox field to run an automation? I want to make sure a certain set of tickets always have a checkbox checked, but I don't see it in the automations to check if the checkbox is not checked.
New Zendesk user here. I have the default "Pending notification 24 hours" automation running, and we've had a couple tickets surpass the 24 hour mark but I can't see anywhere on the ticket where this reminder was sent. When I look at the automations, it shows "4" under the Usage column, but why can't I see that reminder as part of the ticket thread? How can I "prove" that the reminder was sent to the customer?
Hey Ryan,
From within a ticket, you can view the events that occurred, including any business rules (triggers or automations that ran). Details here:https://support.zendesk.com/hc/en-us/articles/4408829602970-Viewing-all-events-for-ticket-updates.
Hope this helps!
Brandon
If the customer doesn't reply and the ticket sets to solved after 48 hours (our resolution SLA is 24 hours), will that report negatively against our SLA?
HiShauni Dring
Resolution metrics use the status of the ticket for starting, pausing, and stopping. Hence, this will depend on the resolution metric you have chosen. For example, the agent work time treats the time in Solved status like a pause. The requester wait time measures the number of minutes a ticket is in New, Open, and On-hold statuses and it pauses on Pending. So you'll only have to make sure that the total time spent in the New, Open, and On-hold statuses is not over 24 hours.
Pleasesign into leave a comment.