최근 검색
최근 검색 없음
Automation Timers - ensuring predictability / removing edge cases
2019년 11월 20일에 게시됨
I've seen a couple articles discussing how automations are every hour, but not "on the hour" - I'm wondering about the finer points of timing an automation... i.e. if you have a multi-step process - like step 1, 2, 3, 4 and you want them separated by "an hour", how do you ensure that the steps are not separated by more than an hour?
In theory (and from what I think I've observed) a multi-step process can seem to SOMETIMES take 2 hours between steps.
Presumably this comes down to the logic where it's been "at least" an hour since the last run...
0 hours 59 minutes and 59 seconds is less than an hour - so that run is skipped...
The next run is around 1:59 from the initial event.
Its not "legal" to say > 0.9 hours to catch any rounding issues...
And yet, setting the hours to 0 could allow automations to fire seconds after the setup condition instead of around an hour later...
Any thoughts on avoiding the edge case? Or is the "one hour or sometimes about two" as close as the system gets right now?
IN THE MEANTIME I think the documentation needs clarification that this variability exists?
I can see a number of applications for this sort of time condition, but my initial goal was to automate some "nagging" actions - if a ticket is older than an hour, send to this group - if it's older than 2, send to that group... the trouble is that variability could lead us to violate our SLAs.
I understand the reason for not running automations more frequently (i.e. by the minute as some people may want) - as that would bring 60x the database load, and quite a performance hit - however it seems sily to have to resort to API and additional work to make the system perform close to what it seems to be described as.
I view the existing variability as a bug.
Any help upvoting this is appreciated - even if the result is just a stable reliable hourly run (which could still result in tickets "50 minutes" ago waiting for 1:50 for processing.
My suggestion for a real solution
Ideally, the load could be mitigated and performance improved by making a new option - lets call it "Asyncronous Automations" - with those enabled, the default run hourly at some point in the hour could be replaced with something more frequent, but filtered to only tickets modified during a narrow window of time...
Automations might have to be better filtered to only be "seen" once per hour, but closer to that actuao hour.
This seems like it would be less demanding on the system than scanning all tickets through an outside API (which is what people seem to resort to now).
Other suggestions welcome.
My only goal is to arrive at something better than "one to two hours" in terms of performance.
Thanks!
m
5
댓글 4개
Nathan Purcell
Mitch has done a great job of explaining my use-case also. The "greater than" option is causing problems and the additional hour has been experienced multiple times.
A bit of transparency of when in the hour our automations are due to run would help. Perhaps being able to link/chain automations (Run B only once A has completed).
Finally, testing is a painfully slow process as I am not aware of any way to work in a unit smaller than one hour. This is made worse given the scenario above with chained automations actually running at 2 hour intervals. If something is not correct I have potentially a three hour wait time for a 2 step process.
3
Michael Plaster
I will echo the sentiment in this thread. I am in the middle of trying to troubleshoot a seemingly basic automation, but the automation schedule doesn't appear to be every hour. We have an automation set to apply changes after X number of hours of a ticket status change, but it doesn't always apply. Reading another forum post it was suggested to change it to >X hours. This indicates that it's known the automation doesn't in fact run every hour. Can we get updated documentation for clarity? In an ideal world we would be given the ability to set the automation schedule for our environment or be able to see when the job runs without having to chase ghosts in the ticket audit trail.
0
Eric
+1 on adding predictability and transparency on automation timers. Very surprised that it was set up the way it is to be honest.
0
Joel Cohen
In terms of documentation, we do mention in this article that Automations run every hour, but not necessarily top-of-the-hour; they will start at some point during the hour. If it is still unclear we can work to improve the documentation.
If you are interested in learning more about this and other features being built please make sure to check out our Community events and Zendesk Updates. Thank you again for your feedback and we appreciate you being a valuable Zendesk Community member.
0