Limit the time and date range when Automations evaluate / tries to run

1 Comentários

  • Joel Hellman

    Here are more details on my Product Feedback post above. I'm hoping we can improve on this area as part of the ongoing review of Automations announced in this post: Triggers and Automations - please share your feedback

    I seemed to just missed the window to leave feedback (the topic is closed for comments), so I'm tagging you @... since it seems you are reviewing this area right now.

    Current support
    Today we cannot directly limit when an Automation is active. It depends your business plan obviously, but in our case, its hourly, so any Automation I create will evaluate its conditions every hour, even if I know it's actions for example should never run on weekends or at night hours. 

    We can indirectly control Automation runs using the following ALL conditions:

    • (business) hours since... status
    • (business) hours... due date
    • (business) hours... SLA breach

    These conditions are quite specific and limiting, and they directly reference the current Ticket's Schedule, which might not be relevant to when the Automation should evaluate.

    Working around it
    If the hours since... conditions is not helping our use case, we can try to "hack it".

    Duck taping Automations and Triggers to limit when an automation will fire, is a classic Zendesk hack if any, I'd say. We've had so many community posts about this over the years, from admins and community members tearing their hairs out trying to figure out a good workaround, but I've yet to find one, that doesn't rely on using API and scheduling externally.

    So here is the gist of how we admins might do this today (exact implementations vary):

    • Have the Automation add a tag when it fires and other conditions are fulfilled.
    • Have a Trigger catch that tag, leverage that Triggers can evaluate Within Schedule: <Schedule>, let the trigger take the action if its within the schedule.
    • This also lets us reference a specific Schedule that doesn't need to be the current Ticket's Schedule.
    • We let the Automation fire until until the Trigger takes an action.

    This brings along Bad Things:

    • An automation can only update a ticket 100 times - you will hit this, but maybe not immediately, and maybe only on certain tickets, after some time. Good luck in catching this, as you won't get a noticed when automation limit is reached either.  
    • You'll spam the ticket audit log. This impact many areas: Zendesk Explore, hard to parse ticket event log, messy incremental exports, trigger run spams, etc.
    • Its hard to overview and reason about this coupling of Automation and Triggers, and it's easy for you or your admin colleague to accidentally break the setup.

    Working around the work around
    Trying to overcome the very real "an Automation can only update a ticket 100 times" limitation, as admins we often add extra logic on duct tape solutions like the one above:

    • We can leverage the Automation's business hours since... status condition (and the fact business hours then limits the time period because it considers the tickets current Schedule (which might not relate to your automation particularly well, but maybe, or better than nothing).
    • We can abuse Triggers a bit, and have a Trigger evaluate a Schedule every time the ticket is Updated, and put the result in a ticket field that the automation could be condition on. Granted, we have no direct control over how often ticket are updated. But in practice we might be lucky, and have some other external process that reliably updates tickets periodically, and we can leverage this as a side effect. 
    • <Insert your own hacky solution here>.

    Even more Bad Things:

    • Now we've introduced even more complex logic and increased the risk our setup will break on a change or not consider possible edge cases that can be hard to think of. 
    • If we use the business hours approach, we tie our business staff schedule with our Automations schedule, but those can have different concerns! Tied together, we can change our staff schedule and the change can have big impact on our Automations.
    • Good luck in explaining how this all works to your new colleagues! 

    Help me keep it simple, Zendesk
    I'm happy Zendesk has done some real improvements lately to make it easier for me as an admin, but whenever I work with Automations, I really feel I'm in the "old" Zendesk.

    I'm not talking about the UI, but the old Zendesk where I have to duck tape everything together with layers of indirection and non-obvious reasoning, when I have to keep lots of thing in the back of my mind, and where I'm never really confident it will work considering all edge cases, when I work with our Automations. 

    I want an obvious and easy solution I can easily explain to my colleagues and my future self.

    I want so that it isn't hard for me or my admin colleagues to ensure our Automations don't send ticket reminders or surveys to our customers at 5 in the morning, or re-opens pending tickets during the weekend when 2 of 20 guys staff the office, or when there is 1 hours left before the end of the shift. 


Por favor, entrar para comentar.

Powered by Zendesk