Feature Request: Trigger - Allow check of group membership of assignee

4 Comments

  • Dan Cooper
    Community Moderator

    Is there a specific workflow that your notifications enable?  It may be worth diving into the reason why the group is getting an email to understand if other options are available.  With other channels like the Slack integration, you may be able to notify everyone without sending emails to everyone. 

    I've seen some teams (mine included) that use the group as a notification target as a way to keep everyone informed or to not drop the ball when new tickets come in.  I've seen in some of these types of workflows that many of the recipients just filter out those emails and the actual problem isn't solved and new problems are introduced with the extra noise.

    Alternatives might be Slack, a shared mailbox, or an adjusted notification plan that sends an email on a delay using an automation if the assignee didn't get to a ticket fast enough. 

    Aside from all those recommendations, I would personally love to see some NOT conditions become more prevalent in triggers.  Hopefully something above can help for now though! 

    0
  • Peter Hochstrasser

    Hi Dan

     

    One of the trigger sets that I'd like to refrain from sending double mails does check for internal (yellow background) updates. Those are important for the assignee, and for first level support.

    We have the first level who does face the customer. Specialists are generally light agents, i.e. they cannot (and shall not) communicate with the customer directly.

    Now, in case a ticket is assigned to a first level member, that person gets two mails, and it would be nice if just one would be received. It kind of fills the inbox pretty fast.

    Slack and other means of communication are not available to all at this time, so they are not an option - e-Mail it is.

    So, my current setup has been to have the assignee notification, and then the group notification to first level. This is important because sometimes, the assignee is on vacation, off work or unavailable for other reasons, so first level needs to know about the update, and handle it appropriately.

    If I could check in the assignee mail if he's a member of the first level group, he'd get only the group mail, not the individual mail. I know, I could hardcode the name(s), but that's pretty error prone and unflexible. A single memberOf check would take care of that completely and would be flexible, clean and elegant.

     

     

    0
  • Dan Cooper
    Community Moderator

    I have a few ideas you might check out: 

    1. It sounds like you want to ensure that a certain amount of time doesn't pass without an update due to an assignee being unavailable for whatever reason.  You could setup an automation to handle the notification to the group instead of a trigger and give a window of time before the group notification.  If the assignee replies, the automation wouldn't send the group email.  Check into the hours since requester update condition in the automation as a starting place. 
    2. Consider using views as a place for your team to work out of.  Having a pure assignee model can be very limiting, and setting a team expectation to keep tickets up to date may help you in this area.  If they can monitor a view and always update the ticket that needs the work now, you should maintain coverage.  This is not an easy suggestion as it may involve rethinking everything you do - but a philosophy of working on the queue as a group over as a bunch of individuals may help reduce gaps (and you can maybe get rid of the assignee email and just stick with group emails here). This can also be made stronger with the SLA feature that Zendesk has that can provide a clock showing when the next update is needed. 
    3. Check out the Out of Office app.  It may allow you to build a workflow that works for your team being out. It's not the most elegant, but if it meets the need then awesome.
    4. Don't send the assignee notification. If the group notifications already go out, maybe you can append the assignee name to the subject so that it's known to the group.

    Hopefully one of these gives you some ideas on how to proceed if you need a fix now while we wait to see if Zendesk can fill in the gap you've described. 

     

    0
  • Peter Hochstrasser

    Hi Dan

    Thanks for your feedback. Since this post, I have completely reorganized the way we create notifications:

    We use tags during the trigger execution to

    • define if no update mail is required, i.e.
    • - if the updater is the assignee then no need to send a notification anywhere
    • - if the assignee is empty, no need to send a notification to a single person, just a group
    • - and lots of other special conditions.
    • trigger the right kind of notification

    The problem is the cleanup of the tags which made me realize that triggers are not executed strictly in order.

    Coming back to your points, however:

    We have SLAs to care for, and things are pretty hairy - we support everything during business hours, but one hour each work day, after business hours, as well as saturday morning, another organization is responsible to manage urgent tickets (but not the others). 

    We use views, and an especially valuable view is the one that sorts the tickets by what type of user has answered last - customer or us including third parties. This way, you immediately see if the customer has answered your questions and can take it from there.

    The Out of Office may help in certain cases, but the prospect of having to manage the on/off status of each agent gives me nightmares (let alone telling people to maintain their status in Zendesk, too).

    Your point 4 sounds interesting, however, it is more or less the reverse of what I try: Notifications should be directed to as few people as necessary (but not fewer ;-)) in order for people to keep an eye on these messages and not just automagically move them to a folder by default - unread and unnoticed. That kind of misses the purpose.

    I hope this gave you some more insights. 

    0

Please sign in to leave a comment.

Powered by Zendesk