Understanding and setting light agent permissions (Collaboration Add-on)

Have more questions? Submit a request

116 Comments

  • Jessie Schutz
    Comment actions Permalink

    Hi Conza!

    So if the employee is not a light agent they will see the email as long as they're cc'd on it. If they reply, the reply will be added as a public comment to the ticket. And yes, they will be added as an end-user.

    The best way to prevent having something meant to be internal accidentally go out as external will be to do an audit and make sure that everyone who is supposed to be a light agent has been given that role.

    You could also potentially train your folks to use the Mail API to ensure that their responses are internal by using the #note syntax at the top of their email responses. I'm not sure whether that particular syntax will work for end-users, so I would recommend that you test it first if you decide to go that route.

    1
  • Sara Gongora
    Comment actions Permalink

    1. Is it possible to limit agents to assign tickets?

    2. How I could restrict the "Task" type of ticket to Admin., only?

    Thanks!

     

    0
  • James Sanford
    Comment actions Permalink

    Hey Sara!

    1. My apologies, it is not possible to limit Agent permissions for tickets to assignment only.  My general recommendation for these scenarios would be to ask your Agents to only perform the actions you wish them to be performing.  The Light Agent Role which is outlined in this documentation cannot change ticket properties such as the Ticket Assignee.

    2. It is not directly possible to limit the Ticket Type field options to a Role.  With that said, you could create a Trigger to change the Ticket Type from Task to a different Ticket Type when a user other than an Administrator updates a ticket if you wished to achieve a similar result.  

    0
  • Cyrup
    Comment actions Permalink

    Can Light Agents Solve tickets?

    0
  • Graeme Carmichael
    Comment actions Permalink

    Cyrup

    No. Light Agents cannot solve tickets or change any of the ticket fields. They only make internal comments.

    0
  • Conza
    Comment actions Permalink

    Hi team,

    Triggers - is it possible to have a "Role is: LIGHT AGENT" , as opposed to just agent? 

    There's quite a few things I want to do that just effect light agents (e.g. stores and internal other department staff), and not agents (who are CS staff for online team)

     

    Has this been raised before? Do I need to make a request? 

    0
  • Ajit Kumar
    Comment actions Permalink

    Hi Conza,

    In order to activate light agents, you will need to list each individual light agent under ANY of the following conditions. So it should read Current User Is [Name of Light Agent]. 

    0
  • Conza
    Comment actions Permalink

    Right, that's an option. But I currently have 619 users in the organisation (in Zendesk), and they're all light agents. So that's not going to happen lol. Is there another way? 

    Use case: they're store staff, franchisees, owners etc. and we're the Online CS team - who liaise with them all. e.g. CCing into tickets etc. and they need to be Light Agents, otherwise - the default is not an internal/private comment. So to be safe - have to keep the list of them up to date. 

    0
  • Zach Wermich
    Comment actions Permalink

    Hello Conza,

    Thanks for reaching out! For clarification on your use case, what was the end goal of this particular trigger, were you hoping to have it so any light agent who attempts to update the ticket, defaults to private note? If not, I'd be glad to initiate a ticket on your behalf so we can discuss this more in detail. Hope to hear from you soon!

    1
  • Conza
    Comment actions Permalink

    The Zach,

    Thanks!

    Re: "were you hoping to have it so any light agent who attempts to update the ticket, defaults to private note? "

    = All their comments are private not, yes?

    The end goal of the particular trigger - was for any light agents (store, internal staff) who update the ticket (whether solved or not), it re-opens it for the agents. So it doesn't get lost or unseen.

    "Light Agent Updated Ticket - Set to Open"


     

     

    0
  • Candace Alexandres
    Comment actions Permalink

    Hey @Conza - I did something similar in our instance. I set up the trigger based on our company's organization rather than a role. Could that work for you?

    1
  • Conza
    Comment actions Permalink

    Thanks Candance for reaching out. Did you have a quick screenshot of that? ;o 
    Could work.. hmm.

    0
  • Candace Alexandres
    Comment actions Permalink

    Sure thing, @Conza! The setup below assumes that one of your light agents is the requester:

    1
  • Zach Wermich
    Comment actions Permalink

    Hey Conza!

    In regards to what Candace referred to, you will want to make sure all of your light agents are part of an organization that is specific to themselves, and then of course use the recommendation placed by Candace above. Cheers!

    0
  • Shawn Oudavanh
    Comment actions Permalink

    Conza, here is my setup. This is if you want any private note that is added that is not from the Assigned Agent.


    1
  • James Sanford
    Comment actions Permalink

    Hey Shawn and Conza!

    Please note that these Trigger configurations are an attempt to overcome product restrictions associated to the Light Agent Role (Light Agents cannot modify ticket properties).  Workflows of this nature can conflict with our Master Subscription Agreement.

    If you need your Light Agents to be updating ticket properties we would recommend moving them to a full Agent Role.

    0
  • Shawn Oudavanh
    Comment actions Permalink

    As I am happy to oblige, can you help point to me where this article is in the MSA? It's quite the read.

    0
  • Candace Alexandres
    Comment actions Permalink

    Hi @James - I just want to point out that the trigger I used and showed above was only put in place to help us provide a more seamless experience for light agents when they are the ticket requester since all of our employees are light agents and frequent ticket requesters. We plan to walk back all of the workarounds in place and move to the Agent as Requester EAP once it includes light agents. 

    0
  • James Sanford
    Comment actions Permalink

    Hey Candace!

    If your Light Agents are the Ticket Requester they will already have the option to change the Status (Though this would not occur automatically if they are updating via email for instance. Also, please note that in this case the workflow you are configuring this for is not bypassing the limitation of the Role since Light Agents would have this access natively as long as they are the Requester).

    Light Agents can "edit ticket properties for tickets they're requesters on after the ticket is created."

    To ensure your Trigger in this case is only affecting tickets where the Light Agent is the Requester you can modify the Trigger conditions slightly, this would be my suggestion for handling this particular workflow in a way that would prevent any conflicts with the nature of the Light Agent Role itself.  (This does assume the ticket is being set to pending/solved when being responded to by full Agents)

    Shawn,

    A quick note on your Trigger recommendation, whenever possible you will want to avoid using "Status is New" and instead make use of the "Ticket is" condition. Triggers: The importance of the 'Ticket is' condition

    (Edit: Please note that I am a Customer Advocate and not a member of our Legal team.  This response is based on my interpretation of the Master Subscription Agreement with the intent to inform and ensure awareness)

    Ellipsis used for clarity and conciseness.  Please also note consultation (the purpose of Light Agents) under the Definition for Processing/To Process/Processed in Section 1.

    2.7 "... Subject to any limitation on the number of individual Agents available under the applicable Service Plan(s) to which You subscribed or applicable Deployed Associated Service, access to and use of the Services is restricted to the specified number of individual Agents permitted under Your subscription to the applicable Service....You agree and acknowledge that You may not use the Services, including but not limited to the API, to circumvent the requirement for an individual Agent Login for each individual who (a) leverages the Services to interact with End-Users; (b) Processes data related to interactions with End-Users..."

    While the action of modifying the Status to Open for Light Agent comments is relatively minor in the grand scheme, as a consultant for these requests who do not have access to modify this value natively (outlined by the restrictions for that Role within this article) this can be considered circumvention of the requirement for that user to have their own full Agent Seat.

    0
  • Conza
    Comment actions Permalink

    Hi team,

    My current setup - when I close a ticket "marking as solved", when the ticket has been raised by a light agent - it first automatically re-opens the ticket. 

    I then have to go back into it - and hit "solved" again, then it stays solved. 

    What am I missing here? What should I be adding in to stop it reopening when an agent solves it, but opens when a light agent responds? 

    0
  • Jonathan March
    Comment actions Permalink

    Hi Conza,

    Check the event log for such a ticket (see https://support.zendesk.com/hc/en-us/articles/203691176-Viewing-all-events-of-a-ticket). From this, you'll be able to see exactly which trigger re-opens the ticket.

    0
  • Conza
    Comment actions Permalink

    Hi Jonathan,

    Thanks. I was aware what trigger (the one I setup), but not sure what in there I can add to make sure it doesn't trigger when the agent themselves solves it. 

    • Status On-hold Open
    • Total time spent (sec) 2154 347
    • Time spent last update (sec) 1807 9
      Trigger "Notify requester of comment update "
    • Status Open On-hold
    • Trigger "Light Agent Updated Ticket - Set to Open"
     
     
     
     
    And oddly now... if I put it to "on hold" and it stays in open? No note/event on why that is in the ticket.  
    0
  • Jonathan March
    Comment actions Permalink

    Ah, I think I see. Looks like you are confusing "Solved" with "Closed". Please see this article:

    https://support.zendesk.com/hc/en-us/articles/203660386-What-is-the-difference-between-a-Solved-ticket-and-a-Closed-ticket-

    It might help to have more context -- we know that you *don't* want it to open tickets that you have solved, or put on hold, but what is it that you *do* want it to do? I.e. what is the intended purpose of this trigger?

    0
  • Conza
    Comment actions Permalink

    Hmm. I understand the difference. 

    I want agents to prefer actioning as "solved", and if customer responds etc. it reopens, or if a light agents adds further comments, it re-opens. 

    If I change the status to "Not changed to solved", that'd work? 

    When an agent / assignee solves it, that's fine. But when a (light) agent responds to a solved ticket, it is re-opened?

    * Quite a bit of elaboration a few posts above about what intent is.

    0
  • Brett - Community Manager
    Comment actions Permalink

    Hey Conza,

    If I'm understanding your use-case correctly, what if you just add the Status > is not > On-Hold condition to your trigger so the ticket no longer re-opens when it's in that status?

    Let me know if I'm mistaken!

    0
  • Conza
    Comment actions Permalink

    Thanks for the suggestion Brett.

    If the light agent comments though, and the status is on hold - that won't then update the ticket to open though?

    The likely reason it is on hold is waiting for the light agent response too.

    0
  • Brett - Community Manager
    Comment actions Permalink

    Ahh thanks for the clarification Conza.

    I think we should take a step back here just so we're both on the same page.

    When would you like for the update from the light-agent to re-open the ticket and when should the update from the light-agent not re-open the ticket?

    Additionally, is the screenshot you provided of your existing trigger current?

    Let me know!

    0
  • Conza
    Comment actions Permalink

    Re: "When would you like for the update from the light-agent to re-open the ticket "

    = Always re-open from light agent, with any response. The light agents are generally stores, helping assist with orders. Our online store agents liaise with them all. A ticket will generally get solved, but then a store (light agent) might respond further, and a lot of messages were getting missed - because they were not getting re-opened. 

    Re: "and when should the update from the light-agent not re-open the ticket?"

    = No instances I can think of. Any suggestions of when I might not want that to be the case? Haha, maybe if they're just saying thanks, but not worth creating an added rule for. 

    The problem is the distinction between agent and light agent it seems. I don't want tickets to re-open when the agent is actioning it into (e.g. pending, hold, solved), but any response from the light-agent in those states - needs to put it to re-open, so our online CS agents can see and action, or solve again.

    Re: "Additionally, is the screenshot you provided of your existing trigger current?"

    = Correct. I removed, when "current assignee is not updater" because that was disrupting things. In that I thought that would not include the light agent, but it does as well. 

     

    0
  • Brett - Community Manager
    Comment actions Permalink

    Thanks again Conza :)

    You are correct and there's no way to differentiate between a light-agent and a regular agent within triggers unfortunately.

    Depending on the number of agents you have on your account, you could use the **Other: Current user > is not > (agent name)** condition for each regular agent on your account. Sample screenshot below:

     

    Of course this isn't really scalable if you have hundreds of agents on your account but if you only have 10-20 this may be possible.

    Another possibility is to have the trigger look for the channel these updates are coming from. If your regular agents reply via the agent interface but light-agents reply via email you could also use **Update via > is > Email** condition along with  **Other: Current user > is > (agent)**. Another screenshot below:

    How does that look? 

    1
  • Jonathan March
    Comment actions Permalink

    Conza, for situations when the light agent *is* the requester, then you can give all your light agents a particular tag (say "light_agent"). Then all tickets for which they are the requester will automatically have that tag, and your triggers can respond accordingly. 

    1

Please sign in to leave a comment.

Powered by Zendesk