Restriction on individual tickets or groups

63 Commentaires

  • Monica

    Adding another vote to this as well.  We're on Enterprise and have enabled Custom Roles with group restrictions.  But it truly doesn't do what we want it to do.

    We have a small subset of tickets that agents in groups A, B, and C shouldn't access, but it's helpful if they have access to tickets outside of their groups otherwise. Ex: First response agents get a ticket that references an earlier ticket that ended up in a different group so they need to review the older ticket to check if it's the same issue and should be moved to the different group.

    I'd love an addition to Custom Roles where in addition to only view tickets in their group, I could select can access all tickets except in groups X, Y, Z, etc.  This would allow me to give them greater visibility but limit from areas they don't need.

  • Alex McFarlane

    Any update on this from Zendesk?  We are using Zendesk in an HR setting but cannot expand our use of Zendesk without this kind of functionality. 

    Although we love the system this means our long-term plan will have to be based on moving to a different product.

  • Caleb Strawn

    Adding another need for this workaround as well! Here's how I explained our situation in a support request:

    Instead of limiting an agents ticket access by what's relevant to the agent (group, org, etc.) I'd like to be able to limit access to tickets by what's NOT relevant to the agent. 

    Example: 3 Agents: A, B, and C. A is assigned to groups 1 & 2, B to 2 & 3, and C to 1, 2, 3, & 4.  We need to set up Agent A to be able to access tickets in groups 1,2 (and 3 if needed) but not 4 (in any case). Specifically, the issue here isn't Group 4 tickets, it's Agent A's ability to access tickets in group 3 without actually adding them to that group because they aren't organizationally part of that group.

    Here are the top 2 solutions that come to my mind:

    1) to set Agent Permissions based on ticket fields not Agent fields(Groups). Or, maybe better,

    2) create Ticket Field - Value Permissions, when setting up the ticket field, you can assign Agents or Groups who CAN or CAN'T view tickets with a specific value in a ticket field. 

    I'm sure that's easier said than done though. I'm hoping there's some kind of solution in the near future!

  • Dan Cooper
    Community Moderator

    I have found that I've made decisions to split teams into their own instances of Zendesk because of this scenario.  I want an environment where agents can collaborate, but I also need a way to restrict tickets in certain areas so that only certain agents can see tickets.

  • Joel Hellman

    Karyn, if you want to restrict tickets access for your agents, the only viable mechanism is to restrict by Group.

    If you really need to restrict tickets, consider if it's okay that all your agents only see the tickets in their own group. You will lose the high level overview of the customer, and deal with access / visibility issues when escalating tickets between groups, but that's the trade-off. 

    There are various 'hacky' solutions based on group based restrictions that includes creating 'umbrella' groups etc, but all of these will mess with your reporting, the built in tickets fields and rules, the quick 'assign to me' links, etc. I really tried it, but had to give up eventually since it became complex and didn't scale, and I really wouldn't recommend it, it's not a fun trip.

    I think we need to await until Zendesk recognize the business case here, and implements a distinction between ticket access and ticket groups/assignee. 

  • Amber Barnes

    Also would find this feature to be very useful. We have a few teams that work tickets with sensitive merchant information, which we cannot have any other groups in Zendesk having access to. These teams that work with sensitive information, do however need to be able to see other tickets in the desk. Definitely looking forward to an update. 


  • Theo Fryer-Smith

    +1 we have tickets that need to be restricted to a subset of agents because of the legal sensitivity of the content.

  • csabm

    Seconding Monica's comment here - a Custom Role where we could set an agent to access all tickets except in groups X, Y, Z, etc. would be ideal. 

  • Justin

    +1. How would an organization handle HR / confidential requests? We have agents that need to be able to see tickets from other groups, but not EVERY group.

  • Logan Bates

    +1.  This has been a big obstacle for our organization too. It disrupts everything from ticket workflow to account settings. Restricted viewing access for a selected group, or groups, that contain sensitive information would be an extremely useful feature and would reopen options to the features that make Zendesk great but we are currently unable to use.

  • Joel Hellman

    The mechanism used to control ticket visibility (for me that's groups) is one of the key recipes for messiness that is still on my top complaints about Zendesk Support. I first commented on this 4 years ago. altough I understand it's a core concept of the Zendesk model, so I suppose it's not trivial to change.  

    It's not the first thing you realize as a new administrator, but visibility on tickets are coupled with groups, which are in turn coupled to lots of other stuff - views/macros/apps/email notifications/assignee field selection, visibility in help center, reporting, etc - and it can be a recipe for lots of administration trade-offs and headaches. 

    I would be very happy if Zendesk introduced a better mechanism to deal with ticket visibility, as well the related issue to decouple ticket carrying groups from groups that are used to achieve other things (such as views). 

  • Simone Pace


    Just confirm that having access segregation paired with groups is an absolute nightmare.

    You should add the same feature as you did for views that now are linkable to multiple groups. Something very similar you should do with access permission so that we can specify to which group's tickets a given role have access.

    Corporate IT for example might easily need to access all tickets but the HR's ones. This is currently not possible.

    Who knows how many customers you're losing for this :-)

  • Erin Boyle

    Hi Kristin,

    Thanks so much for sharing your use case with us. I've actually been hearing an increasing number of customers talk about something very similar. Where our current restricted agent functionality locks a particular agent to accessing a subset of tickets, you really need a way to restrict a subset of tickets from most agents. This is something we're talking about and considering internally, though nothing can be called "planned" just yet.


  • Joel Hellman

    Great feedback Kristin. I'm adding my vote, as our use case is essentially the same. It would help us scale our Zendesk to groups which we currently can't put into Zendesk.

    Currently, if you simplify a bit, ticket access today is all or nothing. Trying to implement a compromise and it quickly becomes complex situation with lots of overhead admin and side-effects. 

    There is usually a good business case too, to have as much ticket visibility as it makes sense for your organization. It would be great to have support for this.

    Restricting access is also a good practice when it's done just for the purpose of removing excess information, as it could be for automatic orders and other ticket types which may not be relevant to most users to have visible on a user profile. Another good reason why we'd like better support here.

    There are lots of cases where multiple groups should have shared visibility, or cooperation becomes troublesome. Like when escalating tickets between teams working in Zendesk.

    For us, ticket access is not as simple as based on which team handles the ticket. One team may handle serveral sets of different tickets where some needs to be restricted to certain groups, and others should be visible to many. 

    In essence, our company's need is to restrict tickets based on content, not simply based on the team currently assigned to the ticket.

    Content is not simply text based of course, it's a business decision which involves the type of recipient the ticket was created towards, the channel, etc.

    We apply stricted restrictions at ticket creations for some channel, as this is the most sensitive stage in the lifecycle, as the ticket content we get could be unknown, and then we ease up during or after the ticket has been processed, as we determined it's nature.

    I'd strongly like ticket access as an independent property in itself, one that can be freely manipulated and which can include as many or as few groups as we'd like. And one that doesn't interfere with reporting, group notifications, assignee fields, and the like, as today.


    I am in the same situation and am pleasantly surprised to see so many other people asking for the same requirement. It would be great if ZenDesk provided a way for us to restrict the visibility of a very specific set of tickets (say, if a ticket is assigned to an agent in a specific group). As Kristin mentioned above, this is required only for some sensitive tickets (which comprise less than 1% of total volume, but have the highest attention).

    It is interesting to see that this request has been lying around for more than 18 months with no solution or workaround from ZenDesk.

  • Produto Ti

    Any workarounds?

  • Alex McFarlane

    We need this too!

  • Johanna Spittle

    Any workarounds here would be great. We receive occasional emails with highly sensitive information in them that cannot be deleted due to legal concerns. Being able to restrict single tickets without having to fully restructure the Group org would be ideal. 

  • Kristin Bouveng

    @Zendesk - no reply in quite a while.


    Can you give any indication on whether this is on the roadmap at all?

  • Kevin van de Riet

    @Zendesk - Any update?

  • Janiece Caldwell

    Any updates on this? Splitting into another instance is not ideal and would love to be able to restrict a subset of tickets from most agents.



  • Frank Kao

    Adding my vote

  • Daniel Savage

    +1 !

  • Pete

    Same here

  • Elyssa Kolber

    This is a highly needed feature.  For our case, we are trying to lock social-created tickets so that non-authorized agents are not publicly Tweeting or posting on our Facebook account.  Considering the added security features needed to set up the social accounts, I was shocked that once linked every single agent has the ability to handle one of these tickets with zero ability to silo.

  • Danny Cohen

    +1 For this feature. It's not practical to add agents into many groups when we want to restrict the tickets that need to be restricted and worked by only one group. 

    Sean FitzGerald for visibility. 

  • Stephen Belleau

    Joel Hellman well said and fully agree! In the meantime I'll share what we've done to work around that - specifically, how groups are not only used for ticket access, but also view/macro visibility and even knowledge management user groups. 

    For each product we support, we create what we call a "user group" that is never meant to have tickets assigned to it. This is the group that we use for view/macro visibility. For example [UserGrp - Product A]. Of course that comes with necessary training for agents to never assign tickets to a bracketed group like this - and optionally, notification triggers for the rare case that does happen (or even a custom ticket sidebar app to strictly prevent that from happening). 

    It's not perfect but it's worked well enough so far, especially for use cases like escalations / tiered support. If a ticket is escalated to a tier 2 group, we want tier 1 agents to retain visibility for that ticket. So ALL tier 1 agents also belong to the tier 2 group. Then, the tier 2 agents who actually handle those tickets are part of the [UserGrp - Product A Tier 2] group, which is used for their ticket view visibility.

  • Fallon Albrecht


  • Michael Penland

    +1 Segmenting channels and topics is needed, at least for sending public responses.  Primary use case is we don't want all of our agents to have the ability to send out public tweets.  Thanks.

  • Henrik Heusala

    Voicing on opinion on the subject: This is a basic functionality in many other ticketing systems. This is also part of the problem why many other ticketing systems are hard to use and manage.

    Even if there would be a perfect technical solution to hide details from different agents based on this and that we are left with the managing part which gets hairy very fast.

    As soon as we start to restrict the whole 360 view of the customer which is the basis of modern multi channel customer service systems and processes and have a situation where we can't trust that all that we see is really all that there is we are sort of "going away" from the whole idea on which for example Zendesk runs on and does a pretty good job.

    On technical side then at first glance this feature request for limitins groups out totally seems pretty straight forward but when you start to go into details and start to really look into what to do with the user profile, what to do with reporting, how this affects different apps and channels etc it also get very hairy.

    What we have as a Zendesk partner done with customers is we have left these groups out of Zendesk for the time being. Not just because you can't do it easily but also because when you start limiting and managing those limitations many times, not always, but many times even without the technical limitations we have come to the agreement that adding these restrictions would hinder and make difficult all the other work in Zendesk to that point that things work better and more efficiently if we keep the 360 idea of the customer inside Zendesk which everyone can count on.

    Saying all this, as a Zendesk Partner we have a lot of customers who are asking for this and a lot of customers where the deal might hang on this kind of a feature so really looking forward if Zendesk finds a way in the end to implement this and other kind of Enterprise restrictions which are found in other systems but do these implementations in the Zendesk way so that it's not a total pain in the **s to both work with and manage :)


Vous devez vous connecter pour laisser un commentaire.

Réalisé par Zendesk