When does the requester field show in a ticket?

Have more questions? Submit a request

5 Comments

  • Christophe
    Comment actions Permalink

    Is there a way to hide the requester field for Agents? Or avoid that they have access to the whole database of users who submitted tickets?

    1
  • Dan Cooper
    Comment actions Permalink

    Hi Christophe,

    I don't think you'd be able to lock this down. There are a lot of ways to surface the requester if you have access to the ticket. 

    The requester is visible as a column in views, as a placeholder that can be applied via macro (or just by typing {{ticket.requester.name}} into the comment field.  It shows up under the subject line and in the ticket sidebar.  While you can use the Zendesk App Framework to hide certain fields in the ticket sidebar - I don't think it would apply to the requester as it has a special place under the subject line. Users are also visible in search results and in the reports they have access to (if you open up one report that has a filter to see requester - then the agent has access to all requesters again). 

    Custom Agent roles can be setup to limit access to users which might get you closest, but if an agent has access to the ticket, they'd still have access to that user. This is probably the closest you'll get to limiting the scope of what your agents will see. 

    If you have end users that should not be seen by certain agents (say you have an exclusive list of users) you might consider having a dedicated Zendesk instance with agents that have special privileges in that instance.  This is the only way I'm aware of to make sure that they are completely separate from the broader agent base. 

    1
  • Christophe
    Comment actions Permalink

    Hello Dan,

    Thank you for your answer, we have to do such implementation for GDPR reason.

    We have been able to restrict the access to tickets through a structure of groups (the search will not display any result if the agent don't have access to the ticket), we have also restricted the download access but your the requester field was my remaining problem.

    So if I understand you correctly we have 2 solutions:

    1) upgrade our plan so we can implement "custom role", will this really restrict the access to all the database?

    2) implement a custom framework to hide some information

    Am I correct?

    0
  • Jimmy Rufo
    Comment actions Permalink

    Hi Dan Cooper,

    Do you know of a way to expose the requester field conditionally in a client facing ticket form?  The condition would be if an agent accessed the ticket form externally, and had to put in a ticket on behalf of a client.  The non-agent end user should not be able to see the requester field in this case.

    Our use case is we do have many internal consultants submitting tickets on behalf of clients.  However, when that happens, the requester shows that its from our own organization, so we don't see the client organization info.  The client organization is tied to integrations with Salesforce data that shows additional info we may need about the client.

    If our only option is to use the "+ Add Ticket option" to create a ticket manually within the agent interface and set a requester there, that's fine, but just wanted to clarify.

    0
  • Dan Cooper
    Comment actions Permalink

    Hi Jimmy Rufo

    You can look into the Requests API to create your own web form that allows for you to set any requester that you want.  

    You might look at the anonymous requests section of the Create Request endpoint to see what settings are required, but you can pass a requester email address in with the ticket and it will set the ticket to that user instead of the person submitting the ticket.  If you pass that value in along with the other ticket details from your form you can accomplish this. 

    You could alternatively look at swapping the requester once the ticket is received if a certain field is populated.  You'd have to cross reference the user email address against your user list for the requester id and then pass that back in via the Update Ticket endpoint - but you might be able to automate this with a trigger that activates an HTTP target that hits the API. There are a few examples in the community about how to use triggers to activate targets for other use cases that can give you ideas on how to push APIs this way.  Initially, I thought you could get away with a single trigger and target - but you have to do the email to id conversion for the new requester which would take a bit more workflow design than I can commit to for this post. 

     

     

    0

Please sign in to leave a comment.

Powered by Zendesk