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 standard automations,About the standard Support 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 tagis现在的机票,自动化不会每form 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.假设一个门票更新10:15am满足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.
70 Comments
HiBrandon Tidd,
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.
HeyHannah 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.
移动那些“任何”条件“所有”年代et you straight.
Current: "If [Status is Pending AND Greater Than 24 BH] AND [Group Is Not AORGroup 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 AANDGroup Is Not B], Close The Ticket" >> If in Group A Or B, "All" Conditions not Satisfied.
Cheers,
Brandon
Brandon Tiddthis 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.
HeyHannah 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
Brandon Tidd
引用Krunk从皇帝的新沟“哦YEAH. It's all coming together".
I love this whole exchange. Thanks for helping, with that explanation,Brandon Tidd. And glad you got itHannah Lucid!
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?
Hi Edrolo,
Unfortunately, it is aninborn rulethat Closed status tickets cannot be updated and this also includes changes made byautomation or other business ruleseven if the actions indicated in them do not make any change to the ticket and is targeting a requester field.
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.
Pleasesign into leave a comment.