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 Creating 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 start at some point during 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.
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; 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 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 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.
Hi @... @... - is the following possible?
I'm looking to use automation to add and remove a tag for organizations based on the initial onboarding -> launch period with our business, rather than using automations to shape a particular ticket's lifespan.
Hey @... -
While Triggers & Automations are focused on the lifecycle of a ticket, you could 'piggyback' off this process to update the user profile using Triggers, json and Notifying External Targets. When an employee is onboarded, create a ticket with them as the requester... this is used to add the organization tag. Then, when the initial onboarding period is complete, (x hours after a ticket is created), push an update to solve the ticket, which would be used to remove the tag. It would look something like this:
Trigger: Ticket is created, New Hire box is checked, notify target "Add Org Tag"
Notify HTTP Target
Automation: Hours Since Created > X & New Hire Box Checked
Uncheck New Hire Box, notify target "Remove Org Tag", Status: Solved
More information here: https://developer.zendesk.com/rest_api/docs/support/tags
Hope this helps!
I've been wondering why is one of our automations never executing. Now I found the answer: automations don't run on closed tickets. What good are conditions like this below if they mean that the automation will never execute?
We would use it to remove a certain tag from users after X days has passed since ticket closure.
Is there a community thread for requesting automations run more predictably?
To have them running "at some point" in the hour is quite difficult to work with in both testing and production and a more granular approach would be a great quality of life improvement.
Hi Nathan -
Yes, here: Automation Timers - ensuring predictability / removing edge cases
Be sure to add as much detail to your comment as you can about the nature of the problem you face because of the unpredictability of automation timing: the problem that causes, how you get around it today, the level of business impact, and how you'd like to see it improved. Thanks!
Cheers Dave - that post sums everything up pretty well. Hope this gets some traction as working with automations (particularly chaining and testing/dev) is very difficult right now.
Is there a way to set a trigger based on who the ticket was addressed to?
Context: Customers often tend to address the tickets to agents with whom they have had a good experience. This need not be the last agent they interacted with. So if a customer reaches out to me:
< Ticket content>
Is there a way to automatically triage this based on the agent name it's been addressed to?
It's not an exact science, but you should be able to Trigger an assignment based on keyword matching.
Hope this helps!
Why is it possible from the interface to select a close status to activate an automation if it doesn't work?
Could you please remove what is not possible to do or allow this?
It forces me to create an open ticket which makes my overall stats wrong.
While you are correct that leveraging "status is closed," "status changed to closed" or "hours since closed" as a condition cannot yield an action on that ticket itself, you are able to create other actions around that event, such as notifications.
I'm not sure I understand your last statement regarding forcing you to create an open ticket. If you could explain your use case a bit further, we may be able to offer additional assistance.
Hope this helps!
Brandon Tidd, you are probably right. Still, I can't send en email after a ticket is closed for X days. The interface allows me to configure that (no warning) but it doesn't work. Had to do this with an opened status ticket which drives to overall stats that are wrong.
Why not testing correctly what is possible and what is not possible ?
A ticket can be held in a new, pending or on-hold status indefinitely. A ticket that is "resolved" can stay in a status of solved for up to 28 days - this is what I refer to as a soft close. During this time, the ticket can be reopened and edited. If it is reopened, the 28 day clock starts over the next time it is solved. Once the ticket remains solved for 28 days without activity, it does move into a hard close status of "closed," from which point it can't be reopened or edited and the only option will be to create a new ticket.
The logic here is that tickets are intended to be incident based - and if the incident has been solved for more than 4 weeks, any follow-up is most likely associated with a new occurrence of the issue. More information about Solved Vs Closed can be found here. Hope this helps!
Hello Brandon Tidd,
This doesn't help at all.
I'm saying the automation allows to create workflow that will never happen. This needs to be corrected (remove this possibility as well as others when some triggers are missing). No question here just a fact.
Thanks anyway for the time.
Ahh thanks for the clarification. Yes, I see what you're saying. Automations will block you from creating a rule that will run every hour, but there is no safety net for creating a rule that will never run. I would suggest cross-posting this over to our Community's Product Feedback section.
I am having an issue with setting up a pending notification email to clients at intervals.
Ideally this will automate with additional stages that will end with closing a ticket. However, it doesn't do anything. If I put the ticket status before the hours it demands the ticket make a larger change. I don't need this to happen.
The only field that changes in the subsequent automations stage 1-3 is the amount of hours since the ticket was set to pending. Logically what I have should work but there appears to be some catch that I can't choose to ignore because Zendesk has it hard coded in that the status or priority must change for this to be allowed. Please advise. Thank you.
Hi Robert Houston -
In this case, "Hours since pending" will be cumulative, so you'll need 3 automations. In this case, we will want to use greater than opposed to is, since automations don't always fire at exactly the top of the hour. So your first automation would be "greater than 72" (3 days) the second would be "greater than 144" (6 days), and the last one would be "greater than 216" (9 days). Something else to call out is that I notice your using business hours. If you have a standard 8 hour business day, you'll need to adjust those down to 24 (8x3), 48 (8x6) and 72 (8x9) business hours, respectively. You could also just use calendar hours and stick to the original hours.
Let's say, for example, your hours are 8A-4P M-F and a ticket comes in at 3PM on a Friday and is immediately responded to and put into a pending status by your support agent. Under 24 business hours, the first automation would run around 3PM on Wednesday. On 72 calendar hours the automation would run around 3PM on Monday. On 72 Business Hours the first automation wouldn't run for 11 days (72 hours / 8 hours a day, excluding the weekend).
One other thing to note when using greater than opposed to "is." Since automations run every hour, you'll need a negating condition to stop the automation from running in hours 73, 74, 75 etc. So, all together, this is what it looks like:
Automation 1: If Status Pending & Business Hours Since Pending > 24 and contains none of the tags pending_notificaiton1, then send reminder #1 and add tag pending_notification1
Automation 2: If Status Pending & Business Hours Since Pending > 48 and contains at least one of the tags pending_notification1 and contains none of the tags pending_notificaiton2, then send reminder #2 and add tag pending_notification2
Automation 3: If Status Pending & Business Hours Since Pending > 72 and contains at least one of the tags pending_notification1 pending_notifcation2 and contains none of the tags pending_notificaiton3, then send reminder #3 and add tag pending_notification3 and set ticket to solved
Lastly, you'll want a Trigger that 'resets the clock' if the end-user responds:
Trigger, if ticket is updated and status changed from pending
Remove tags pending_notification1, pending_notification2, pending_notification3.
More information about this process can be found in the Bump Solve automation documentation. Hope this helps!
Hello Brandon Tidd,
I have 4 automations set, all with increasing amounts of time. I also have an automation for when a client responds to set the status to open. The original pending automation was working then it just stopped. It isn't running at all.
As an aside, I added tags to each stage and nothing happened. I even reordered the pending status and time to see if that had an effect. It doesn't appear to have.
Hi Robert Houston,
I believe it has to do with your condition that is set to "IS" rather than "Greater than" xxx hours.
This is because automations run AROUND the top of the hour but not AT the top of the hour and can change slightly based on workloads on infrastructure.
If you change them to Greater than xxx hours you'll be fine BUT remember to do the tagging! Here's the recipe to follow: https://support.zendesk.com/hc/en-us/articles/4408832749210-Workflow-recipe-Sending-automated-ticket-reminders-to-customers
I have added tags and a trigger for the initial change to pending in the hopes that this helps. This is the error I get now:
Automation could not be updated as:
The ticket is identical to stage 1-3 with the exception of the hours and the specific tag it looks for and adds. Numerically ascending tags. This error does not appear if the time requirement is first and does not appear for the initial automation.
You're going to want to add the pending_automated_2 tag to the "contains none of the following tags" condition. That's your nullifier the system is looking for.
I have implemented this. I will see if it works. Thank you.
Thanks for the assist, Heather Rommel. Glad you got it working Robert Houston
Heather Rommel Brandon Tidd
None of the automations are running. I remade 1 into an hour as a test, I changed nothing else and its run 8 times. Now I am extra confused. Also, is there a way to see tickets your automation has effected?
Hi Robert Houston
You can apply a marker to the ticket affected by the automation and then set a view based on this.
Automation are not working well for me also.Zendesk should enhance this tool.
Hello, thank you very much for the contributions. I want to set up different automations,
in which I want to send internal notes,
that come out from different senders.
We have each configured different forms
but the same recipient is always shown and we are both admins. Thanks a lot.
I'm not aware of a way to send automations FROM a different user...
Hard to diagnose here, but how many pending tickets do you have right now?
And can you post a screenshot of your "stage 1" automation?
These include the changes you suggested. Whats even stranger is that 2 of them ran this morning and only once. No clue what they did as the recently updated pending tickets remain unchanged.
What's setting this pending_tag_automation tag on the ticket? This looks to me like you'd need this tag on the pending tickets in order to kick off the first one. Are you adding it in a trigger or something? Do you need it?
Its from a trigger that I made for when a ticket is changed to pending. It is meant to add a tag that the automation stage 1 could use to start or force start it. I can try deactivating it but it really shouldn't be an issue. The automation didn't work before or after.
Please sign in to leave a comment.