Restriction on individual tickets or groups

50 コメント

  • Justin
    コメントアクション Permalink

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

    2
  • Leandro Batista
    コメントアクション Permalink

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

    0
  • Janiece Caldwell
    コメントアクション Permalink

    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!

    1
  • Frank Kao
    コメントアクション Permalink

    Adding my vote

    1
  • Logan Bates
    コメントアクション Permalink

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

    2
  • Daniel Savage
    コメントアクション Permalink

    +1 !

    1
  • Alex McFarlane
    コメントアクション Permalink

    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.

    4
  • Pete
    コメントアクション Permalink

    Same here

    1
  • Luana Cristina Do Amaral Peixoto
    コメントアクション Permalink

    Great suggestion.

    To suit us, the restriction could be by function.

    Thank you.

    0
  • Camila Ribeiro Leao Santos
    コメントアクション Permalink

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

    0
  • Justin
    コメントアクション Permalink

    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"

    0
  • Elyssa Kolber
    コメントアクション Permalink

    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.

    0
  • Teri Hines
    コメントアクション Permalink

    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.  

    0
  • Adam Bond
    コメントアクション Permalink

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

    0
  • Corey Gould
    コメントアクション Permalink

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

    0
  • Cameron Greenfield
    コメントアクション Permalink

    +1 adding my vote for this

    0
  • Scott Leclaire
    コメントアクション Permalink

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

    0
  • Danny Cohen
    コメントアクション Permalink

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

    0
  • Joel Hellman
    コメントアクション Permalink

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

    1
  • Stephen Belleau
    コメントアクション Permalink

    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.

    0

サインインしてコメントを残してください。

Powered by Zendesk