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
Matthew
Alejandro,
my apologies for my late response. Thank you for the guidance. we have actually set an automation to raise priority and trigger against SLA under the business schedule. Works a treat. So thanks again.
Matthew
0
Alejandro Colon
@...
No problem.
Yes, I avoided suggesting an SLA as you mentioned it would not work for your situation.
Glad you were able to get something working for you.
0
Anita Rajkumar
"Hours since created" conditions - what is the least value to enter?
0
Bonnie
0
Anita Rajkumar
Thanks Bonnie.
Looks like "0" also works. it runs on the next automation run.
0
Bonnie
0
Hutton, Spencer
Is Hours Since Assigned referring to the First Assignment or the Last Assignment?
0
Joyce
"Hours since assigned" means how long has it been since an agent has been assigned to a ticket - which refers to the first assignment.
0
Jorn
I have problems with a similar setup.
I've got an automation adding a reply and putting the ticket to open when Hours since pending > 168 hours.
But I want it to run, when hours since the last reply is > 168.
I know I can use Hours since assignee update or Hours since requester update.
But when anything is happening in a ticket, it is seen as an update (ie field change). In my situations it should only be a (public) reply.
Any clue how to get there?
0
Dekbi
Apparently, we don't have a condition that will only determine that there is a Public Reply on a ticket. The only available conditions that we currently have are the ones that are listed in our documentation Automation conditions and actions reference.
In addition, I encourage you to create a new post in the General Product Feedback topic in our community to engage with other users who have similar needs and discuss possible workarounds. Conversations with a high level of engagement ultimately get flagged for product managers to review when they go through roadmap planning.
Specific examples, details about impact, and how you currently handle things are helpful for our product teams to understand the full scope of the need when working on solutions. You may also want to review the Product feedback guidelines and how to write an effective feedback post [https://support.zendesk.com/hc/en-us/articles/4413820079386-Giving-Product-Feedback-at-Zendesk-].
We truly value customer feedback and your voice and votes in the forums help influence future Zendesk functionality.
0
mfg
For using the "Hours since pending" condition - does this condition entail that the status is still pending? I've been including a condition that the ticket must be in that status.
0
Dave Dyson
0
mfg
@... - to clarify - "still" as in it hasn't changed from pending? ie. if a status goes from pending to open to pending, am I correct to assume that the clock starts from the most recent (second) time it gets set to pending?
0
Dave Dyson
0
Shane Hughes
Hi,
How do I define the business hours in "(business) greater than"?
0
Dave Dyson
0
Justin Dudek
Dekbi - maybe I should post in a different thread, but...
I have an automation that fires after a ticket is on hold for 96 calendar hours, if ticket contains specific tags/fields. It's fired over 100 times this week, correctly.
I've discovered a lot of tickets, containing the same specific tags/fields, and are status 'On hold', are not triggering the automation at 96 hours.
I just ran a Zendesk Explore report to lookup ticket ID's, w/ on-hold status, and business and calendar hours since on hold - I found that some tickets, despite being 'On-hold' for nearly 24 hours, show their On-hold time - Business hours and On-hold time - hours metrics as 0.0 hours.
Through Zendesk Advanced Search, I've found tickets that have been on-hold for over TWO weeks, matching the same ticket parameters to fire the automation (it's literally a system email with pre-programmed data fields that are identical every time; again, the automation works several hundred times per week, but seems to fails several hundred as well).
So why are some tickets appearing as having 0.0 on-hold hours? And for tickets with way higher than 96 hours, why isn't the automation firing?
0
Dane
If you think that there is an unexpected behavior for your automations, it will be better to contact our support directly due to the nature of your concern.
0
vincent solitario
Hello
Is this possible in trigger or automation?
What we wanted to happen is this.
Agent last reply> after 5 minutes (customer no feedback/reply) sent a message for follow > after 10 minutes (customer no feedback/reply) > sent a message to close the ticket then the ticket is automatic solved
0
mfg
vincent solitario - im not sure if you're using "after 5 minutes" as an example or if you're meaning to go with those events actually happening as measured by minutes specifically , but automations only run about once per hour, so this would not be possible using automations. since there are no updates to the ticket, triggers would not run/fire.
1
Elizabeth
Is it possible to define business hours in the automation conditions? If it is how is it done ?
0
Beto
Hello Ecbo, I hope you are well! Thank you for your question.
You are able to choose between calendar or business hours on any Automation time condition, but you cannot define what those hours are directly on the Automation. You must define them on your schedule first, by following the steps here: Setting your schedule with business hours and holidays.
Once you have defined your schedule, you will have the option of selecting between calendar or business hours on the second box that appears after you select any of your time conditions, like this:
I hope this was helpful!
1
Ofek Cohen
Is it possible to add a column in a field that shows the Hours since the ticket was created?
0
Christine Diego
Hi Ofek,
Ticket hours since created is available as a condition in creating a view. If this is not what you are looking for, I would suggest Contacting Zendesk Customer Support and provide more details about your use case.
0
Rolf Hayes
Dave Dyson (gmail) you mentioned in a post previously that "Hours since pending" requires the ticket to still be in Pending status for the condition to match. I'm trying to get an automation to run where:
These aren't the actual states I'm using as we have enabled custom statuses, but is there a way of achieving this? Will the hour count continue from when the ticket was last set to Pending despite having changed to On Hold?
0
Dave Dyson (gmail)
Rolf Hayes Seems like you could use "Hours since On-Hold" as your automation condition for this, instead of "Hours since Pending" ?
0
Rolf Hayes
Dave Dyson (gmail), Not really as I am trying have the automation fire from a specific status regardless if it has changed to a different status since then.
Let me explain my case a little further. We use ZD Suite to log the booking of engineer site visits to attend to many of the incidents and problems in tickets. I've added some custom ticket statuses to help with this, namely "Visit Booked" and "Visit Elapsed". The visit booked status is in the On Hold category and the visit elapsed status is in the open category.
So far I have tried an automation that runs when a custom date field "is within the previous" 2 days. However this becomes true at 00:00 of the date in the custom date field according to the ZD logic, despite the visit not actually having happened. I really want this automation to run with two conditions:
However the IS NOT function is sadly missing from custom date fields in automations and indeed from much of the ZD trigger and automation conditions.
As a work around I've created a further custom status called Dont Use and is simply for the system to change the status from Visit Booked to Dont Use and then back again with tags. Then a further automation to change the ticket to Visit Elapsed when specific tags and hours since Visit Elapsed Status is more than 48 hours.
I've ended up with 3 automations just to fire one ultimate action which seems absurd. Any advice or recommendations would help as all these automations start mounting up towards the limit of autmoations and maximum number of tickets that run in an hour.
0
Mike DR
The step you did is the workaround for now, I understand this is a neat feature to have what I would love to do with your partnership is attack this from both fronts; on my side, I'll flag a couple of articles for revisions as there are places we can call this out that could expressly mention it so others don't experience the frustrations you've experienced, and on your end if you could submit product feedback as outlined here to communicate use case, headaches caused, etc. so our product team can take it into future roadmap + release consideration I would be greatly appreciative.
0
Naomi
Hello! Is there a way to identify the “Hours Since Tag Added”? Basically a similar behaviour as the rest of the “Hours Since” function, but instead of the ticket status, it should get the hours since a particular tag was added.
For context: Our goal is to automate the process for following up and closing unresponsive tickets. Based on the advise that we found from the community, we already created 3 automations to:
- Automation 1: Follow-up since Pending (3 days)
- Automation 2: Follow-up since Pending (15 days) AND followup_1 exists
- Automation 3: Follow-up since Pending (20 days) AND followup_2 exists
This is fine and things are working as expected for new tickets (tickets that were created after this new automation process).
The problem: We already have tickets that have been pending for 30 days and more before we created these automations. This means, as soon as we activate the 3 automations above, those tickets that have been pending for >30 days will get notified one at a time for the span of about 3 hours, more or less (since the automations will fire hourly and Automation 2 and 3 are dependent on Automation 1 and so on). So instead of getting “Automation 2” 12 days after “Automation 1”, and “Automation 3” 5 days after “Automation 2”, the ticket will just be closed in almost 3 hours.
This is why we would like the filter to be dependent on when the tag (followup_1, etc.) was added rather than the pending status. We cannot use “Hours since update” as a workaround either, since there are times when we send internal comments on already-pending tickets.
Hope there's a way to do this or a neat workaround.
0
Zsa Trias
Hello Naomi,
We currently do not have a time-based condition to base on when a specific tag is added to the ticket.
Only those that are listed when you create an automation are the ones available at the moment.
0