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.
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.
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.
"Hours since created" conditions - what is the least value to enter?
Looks like "0" also works. it runs on the next automation run.
Is Hours Since Assigned referring to the First Assignment or the Last Assignment?
"Hours since assigned" means how long has it been since an agent has been assigned to a ticket - which refers to the first assignment.
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?
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.
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.
@... - 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?
How do I define the business hours in "(business) greater than"?
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?
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.
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
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.
Is it possible to define business hours in the automation conditions? If it is how is it done ?
Please sign in to leave a comment.