Automations enable you to set up time-based actions to modify tickets or send email notifications. One popular use of automations is to perform an action a certain amount of time after the ticket is created or changed. There are two ways to define time-based conditions.
Understanding how hours are counted
- You can only specify whole hours, not days or fractional hours
- The clock doesn't start until the automation runs
- Automations run hourly, not immediately after a condition is met
- Automations can only act on 1000 tickets per cycle. See Understanding how the automations ticket limit works with "Hours since" conditions.
Because automations run hourly, each run counts towards the hours since a condition was met. The first time an automation runs after conditions are met, which could be 1-59 minutes later, counts as "zero" hours and starts the clock. Then, each subsequent automation run counts as one additional hour. After the number of hours has elapsed or been exceeded, then the automation fires and executes the action. It's also important to note that you can only specify time in whole hours.
Let's use the default automation Close ticket 4 days after status is set to solved as an example. This automation changes the status of a ticket after 96 hours or more have passed since its status was set to Solved.
Given this automation, let's say a ticket is solved at 9:15 am on August 20. The first time the automations runs after the status condition is met is 10:03 am (48 minutes later). The count increases by one with every subsequent automation run. The ticket reaches the 96 hour mark when the automation runs at 10:11 am on August 24, at which point the automation fires and changes the ticket's status to Closed. The action to change the ticket's status prevents the automation from being valid more than once per ticket.
Using "Hours since...greater than" and "Hours since...less than" conditions
When creating conditions based on elapsed time, we recommend using greater than and less than whenever possible. This operator gives the automation a bigger window in which it's true and can fire, which reduces the possibility of missing the window. However, automations need to be defined so that they are only true for a ticket once. That means automations that use the greater than and less than operators must include a nullifying condition or action. One easy way to cancel a condition is to add a tag. For example, you can define two conditions that must be met (the time elapsed and the absence of the tag) and an action to add the tag when the automation fires on the ticket.
In the following example, the automation checks for tickets without the pending-reminder-sent tag that have been pending for 120 hours (5 days) or more. When a ticket meets these conditions, a notification is sent and the pending-reminder-sent tag is added. The addition of the tag prevents the ticket from meeting the automation's conditions again.
For more information, see Ensuring your automation only runs once.
Using "Hours since...is" conditions
You can also use the is operator when defining automations based on the time elapsed. When you define an "Hours since...is" condition, the automation fires only during the brief window in which it's true. Because time-elapsed automations with the is operator are only valid for an hour or less, a nullifying action isn't required because there is no possibility of the conditions being true more than once.
The downside to having such a narrowly defined and brief state of being true is that if, for some reason, your automation doesn't run during that hour, the condition can't be met on subsequent runs. Because of the slight variation of run times for automations in any given hour, it is unlikely but possible for an is condition to never evaluate to true. For example, if you define a condition in which tickets were created one hour ago and you create a ticket at 10:03. If the automation fires is at 11:01, the ticket was only created 58 minutes ago and therefore the automation isn't yet true. However, if the next time the automation fires is at 12:06, the ticket was created 2 hours and 3 minutes ago, and the condition fails to be met all together.
Additionally, all automations typically run in order every hour and fire on all tickets where conditions are met, but there are some scenarios that may result in some but not all automations running within an hour. This is only likely to be an issue if you have a lot of automations or a high volume of tickets.
Understanding how the automations ticket limit works with "Hours since" conditions
Because automations can only act on 1000 tickets per cycle, if you have more than 1000 tickets that meet your automation conditions, some will be missed in the hour the automation runs. In this case, use the "Hours since... greater than" condition. This enables the the automation to fire for the rest of the tickets in the next hour. If you use the "Hours since... is" condition, the automation cannot fire again on those extra tickets. They will be missed completely.
41 comments
Sarah Mills
Hi,
I am trying to set up a ‘reminder’ to assignees when a ticket is open greater than X time.
I am not able to as I receive a message: An automation that runs multiple times per ticket is not allowed.
Is there a more suitable approach?
0
Rolf Hayes
Hello Sarah Mills
The challenge you're facing is that there isn't anything within the automation that will prevent it from running repeatedly for the same ticket. You need to build something into the Automation that will ensure that once it has run on a ticket that ticket is no longer applicable for the automation to run.
For example the automation checks that the tag “assignee_reminder” is not present, then runs the reminder and adds the tag “assignee_reminder”. Therefore the automation won't run again as the tag is now present. See below which should help more.
If you wanted to have the reminder run again after a number of hours then you could have a different automation that runs for any tickets with tag “assignee_remider” and hours since the update function, to then remove the tag “assignee_reminder”. Assuming the ticket is still in Open state this would then re-run the first automation giving the assignee a further prompt.
This last point is rather open as there isn't any restriction as to who updates it, and one thing to consider is whether tags are added or removed should the requester update the ticket.
Hope this helps.
0
Bobby Koch
Can you do "Hours since solved.. greater than … 0?
0
Gabriel Manlapig
Hi Bobby,
Can you tell us more about your use case what is the goal of the "Ticket: Hours since solved > Greater than > 0" condition? As you may already know, Automations execute sequentially every hour, firing on tickets where the conditions are satisfied.
For this reason, "hours since solved greater than "0" is more or less functionally equivalent to "greater than or equal to 1", as the conditions are likely not going to be checked on exactly the 1 hour mark as mentioned in our documentation about automations:
0
Bobby Koch
Gabriel Manlapig i am just trying to cheat the system, really.
long story: it all plays into messaging
short story: i thought maybe an automation for greater than 0 would run on the hour or whatever is the cadence that automations run, and then it would look for all tickets that meet my criteria, basically no matter how recently they were satisfied.
Basically I want to close messaging tickets via automation, because the instantaneous trigger is too fast and messes with some of our metrics. We decided to add an automation instead, but an entire hour, sometimes more, feels a bit too long, so I was hoping that i could cheat the system!
0
ERIC C
Anyone know what's the difference between “hours since ticket status category solved” vs “hours since ticket status solved” in this context?
0
Bobby Koch
ERIC C yes
Ticket statuses all belong to a status category as well
So Open = Open cat
new = new category
Pending = pending category
etc.,
This basically gives you flexibility if you use other custom statuses, or plan to in the future, that maybe have a many:1 relationshiip.
My org has “Waiting on Customer” and “Waiting on internal” as two pending ticket statuses. Both belong to the pending category but are labeled as I have in quotes above. So, the automation levers can either let you pick a specific status, or grab the enture category to run your automations.
1
Rolf Hayes
ERIC C the first condition is for tickets in the Solved status
The second condition will include any ticket with a status of Solved or any custom statuses that you've created within the Solved category.
See “Ticket statuses” in your admin side of your Zendesk instance.
1
Sayako Kawata
"Hours since pending" - If we re-save the ticket from Pending to Pending, will it reset the clock, or will it take the first Pending timestamp? Example scenario is, if we update a different field to a Pending ticket and then save as Pending again.
0
Liia
Hi! Can we usr Hours since ticket category solved is less than 1?
We want to send the CSAT request immideately. We tried to use the placeholder {{satisfaction.survey_section}} in macro but it automatically becomes a link instead of the rating form ( as when you insert the placeholder manually)
SO if we can use the placeholder in the macro, can we use automations less than in an hour? Thank you
0
Bobby Koch
Liia just disable it and create a trigger. Should work, I do it that way in my sandbox account.
0