Restriction on individual tickets or groups

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.

I'm also adding my vote. We have a group we want to add to Zendesk, but their emails are confidential and shouldn't be seen by the other groups. 

adding my vote on this. It would be so helpful to be able to restrict certain information. In our case it would be net price calculations.

+1 Adding my vote for this too. We have same scenario with need to restrict access to select tickets (10% of overall volume). Restricting access to tickets with certain groups is ideal, but since we are on Enterprise - even if we could restrict agent role access to certain ticket forms, that would suffice too. Hope to see this access control interface to be brought on new admin framework functionality/interface so we can get more granular with agent access.

Cheers and Thank you

+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.

+1. Precisamos também restringir os acessos de tickets do grupo RH e Financeiro. Atualmente somos forçados a realizar alguns processos fora do ambiente Zendesk para que estas informações "sensíveis" não sejam acessadas por qualquer colaborador.

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.

Thanks!

Adding my vote

+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.
    

+1 !

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.

Same here

Great suggestion.

To suit us, the restriction could be by function.

Thank you.

Excelente sugestão! Para adequar, uma restrição pode ser executada por uma função.

Can we get an update on this highly requested feature? Seems like a lot of companies would benefit from being able to use "exclude" statements for tickets, groups, etc. It's not ideal having to add agents to all groups except one, just to say "they shouldn't see HR tickets"

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.

Adding my vote for this feature as we need to have certain tickets restricted to a group and the current settings are too clunky to be of use.  We would like to have the option to default to all but then eliminate certain groups from the "all" access.  

+1 - need to segment our HR/Payroll groups from all agents, but currently not possible without restricting our agents from viewing all other tickets.  Its clunky to add every agent to all groups.

+1 for this. our accounting department handles sensitive data that should only be visible to them in an organization with many groups. Currently, every other agent must be added to every other group to accommodate so they can access other support tickets should the need arise. Very clunky and difficult to maintain. 

Would be so much easier if I could just restrict anything assigned to the "Accounting" Group to those agents. 

+1 adding my vote for this

+1 for this. We just tried to roll this out to include HR and broke access and triggers for a large portion of our users. I'll have to advise that we not roll this out and that they find another solution unless this is on the roadmap to be addressed soon.  

+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. 

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). 

@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.