Ben Bauer

+1

I've just set up over a dozen triggers and some are using webhooks to call the Zendesk API to update custom ticket fields with parent/child side conversation data that we can later use for crafting reports in Explore. It would be wonderful if an out-of-the-box Side Conversation dataset were added to Explore, so I could retire all this custom "overhead".

 

Thanks,
Ben Bauer
Director of Support
Syniti

Hi Josef,

I just ran into this issue today. This is by no means an ideal "solution", but I made a tweak to our help center website that hides the CC field from both Agents and Light Agents. End-users can still use the CC field. At this point, I'm not aware of a way to distinguish between Agents and Light Agents in the jquery.

1. Go to 'Guide admin'

2. Go to 'Customize design' and click 'Customize' on your Live theme

3. Click 'Edit code' in the bottom-right

4. Scroll down and select the 'script.js' file

5. Paste this code anywhere below the "document.addEventListener('DOMContentLoaded', function() {" line:

//BB|Start|show and hide elements for various users
(function() {

// check if user is signed in
  if (HelpCenter.user.tags) {
    var isAgent;

    // find the element
    function agentCheck(element) {
      return (element === 'agent')
    }

    //go through the HelpCenter object and look for user role
    isAgent = agentCheck(HelpCenter.user.role); 

    // hide stuff from Agents & Light Agents
    if (isAgent === true) {
      $('.request_cc_emails').each(
        function(index) {   
          $(this).css("display", "none");
        }
      );
    }
  }
}());
//BB|End|show and hide elements for various users

6. The jquery might not work until this is added into the 'document_head.hbs' file:

{{!BB|Start|add jQuery Core 3.6.0}}

{{!BB|End|add jQuery Core 3.6.0}}

Our workaround has been to take a custom dropdown field and write a trigger for each item in the dropdown. Of course, as mentioned above, this can grow to a large volume of custom code. I definitely agree that custom dropdown fields should have the "changed" condition added.

Example dropdown list (with tags):

• route to Team A (last_a)
• route to Team B (last_b)
• route to Team C (last_c)

Example trigger list

• If dropdown is "Team A" and tags don't include "a", then add internal notes, assign to group A, and add tag "a"
• If dropdown is "Team B" and tags don't include "b", then add internal notes, assign to group B, and add tag "b"
• If dropdown is "Team C" and tags don't include "c", then add internal notes, assign to group C, and add tag "c"

An example ticket where agents use the custom dropdown field to route from A to C to B will have these tags:

a, c, b, last_b

The one remaining gap in this approach is that you can't have the triggers fire additional times for a single value. For example, if the custom dropdown field goes from A to C and back to A again, then the trigger doesn't fire on the 2nd execution of A. You could remedy this by having each trigger remove every other tag in the set. Of course, that would make adding new values to the custom dropdown a giant pain, because you'd have to update the full set of triggers. And you'd lose the psuedo-history of having all the tags added.