Role Permissions for Groups and Organizations


  • Becky Baylor

    I completely agree with Shannon on this one. We have a few senior staff members who need access to edit organization fields, but they should not be able to create or delete organizations. I set up a security role for "Team Lead" that would allow higher access for these key staff members, but I was disappointed to find that I am unable to designate some of the more granular security privileges that our organization needs. 

  • Collin Cunninghame

    +1. We have users who need to be able to manage the groups other users belong to, but they absolutely don't need the ability to delete or create entire groups. 

  • Dan Sowden

    +1. The level of control around editing, deleting tickets, adding tags etc. should be available for users and organisations too - it's far too easy and destructive for agents to delete users instead of simply suspending them.

  • Amber Martin

    +1! We have over 150 agents utilizing Zendesk and this is leaving to much room for error.

  • Heather Rommel
    Community Moderator
    The Product Manager Whisperer - 2021

    Agree! I upvoted this one.

  • Crystal Carrow

    Agreed and upvoted!


  • Elizabeth Toy

    Also agree that there need to be more granular permissions for organizations, similar to the permission options available for users.


    We also noticed that when a user does not have the permission (add or modify groups & organizations) they aren't even able to see the list of organizations on the "People" admin page. But they could search for and open an organization's page. Just can't see a list of all the organizations...

  • Andrew Yager

    I've just discovered that there is a lack of distinction between organisation and group permissions. Enabling agent permissions to manage an organisation (which we would like to do) also enables their ability to modify the groups that they, or any other user is a member of - potentially opening a huge privacy issue/window.

    I'm actually gobsmacked that there isn't a difference in the way that Zendesk manages these two types of permissions!

  • Arnaud Héritier

    +1000. It makes no sense for all reasons listed above

  • Travis Tubbs

    This is just one of many areas Zendesk needs to improve when it comes to Permissions. There are many posts throughout the Community stating there need to be separate permissions for this and that.

    A much more gradual permission settings feature is desperately needed. I'm having to make way too many people Administrators to do a single task which unlocks a larger subset of administrative features in Zendesk I don't want that person to access.

  • Naomi Watnick

    +1 We have RBAC needs for Organization and User details.  

  • Alejandro Colon


    Can we get an official Zendesk response to this?

  • Steve Steffel

    Just adding that we'd also love this to be separate permissions. We would like agents to update organization fields as needed, but the fact that allowing them to do this also allows them to delete the organization and add a new one (both of which mess up connections with other systems) is frustrating. Not to mention how agents should not be messing with internal groups at all as that can affect routing, reports, etc. Our options right now are to restrict all the permissions to a small group and burden them with changes needed by everyone, or just risk having people make changes they shouldn't.

  • Kane Marzol

    Honestly I don't understand why this isn't already a feature. One of our biggest pain points with ZD is that permissions across the platform aren't segmented or granular for the most part.

    We want managers and specific staff to be able to add organisations in as we get many different new organisations sending emails in, and we need them tracked and in ZD.

    However, we don't want staff with this access to be able to edit internal groups, as this allows for them to remove or add people to groups they shouldn't be in, or to delete whole groups. We've had a similar issue in the past with adding in 'Call Listening' access to certain users w/ ZD Talk, which needed users to essentially have Admin level access to certain features as there was no segmentation of the feature. I believe this has been fixed now, but seeing this kind of segmentation across the whole suite honestly should be a requirement.

    Groups and organisations in ZD are separate things, but why is the option to edit them not only combined, but also has the 'add, edit and delete end users' permission as a requirement?

    As Travis and Steve have said above, it hurts our workflow as I need to be doing tasks that should be assigned to staff members who manage the client-facing side of things, but shouldn't have access to managing user groups. 

  • Tim Johnson

    Adding in my own support, as we just started to look into using Organizations, and I'm coming across some funky access issues that seem to stem from how the Role-level permissions are built.

    It seems the optimal solution (at least at the "Accessible Tickets" level) would be to set the "organization" and "group" permissions as checkboxes as opposed to radio buttons to allow for more control over exactly what an Agent can see:

    • Assigned to this Agent only, plus:
      • Those within this Agent's assigned Organization(s)
      • Those within this Agent's assigned Group(s)
    • All tickets regardless of Organization/Group membership

    (the indented options would be checkboxes, while the outdented would be radio buttons)

    The current issue is "Requested by end users in this agent's organization" and "All within this agent's group" are an either/or function. There's no way (that I can find) to give an Agent the ability to see tickets in both their Org and Groups without allowing everyone else in their Org to see all tickets in that same Org (via the "view all org tickets" permission set at the Org level). 

    We have dept. managers who are both End Users and Agents in our setup. We want those managers to see the tickets requested by those within their Org, but do not want those End Users to see other's requests (since we have a single Instance and HR tickets are in there).

    I believe by allowing us to define access to Groups, Orgs, or both at the Role level, we can make this happen. If there's a current solution to this, please let me know!

  • Alina Wright
    Zendesk Product Manager

    Hi all,

    I'm a new product manager here at Zendesk and catching up on this thread. I'm taking over roles and permissions so this is all incredibly relevant feedback as we're focusing on more granular permissions for our customers. Things we are currently researching include breaking out permissions under roles, brands, groups, and organizations. We hear you that making someone an admin for a non-typical admin task doesn't seem appropriate and overkill in terms of access. 

    We're currently working on all the backend infrastructure that would enable us to break out the permission settings in roles -  so once we've gotten that to a good place, breaking out the permissions will come at a much quicker pace.

    Thanks all for your patience on this! We hear you and we're working on it. 

  • Nathan Purcell

    Any update Alina Wright

    I agree with all of the above and would like to add to the list a wish to set permissions (RWX) on each area of Zendesk. 

    I had a request from a team leader today to be able to set his agents OOO if they call in sick - as far as I can see right now, the only option for me to grant this to him is the elevate him to Admin, which as stated before, is absolutely overkill! 

    This request was first opened 4 years ago. 

  • Alina Wright
    Zendesk Product Manager

    Nathan Purcell - unfortunately I don't have any timeline updates for you regarding breaking out groups and org management on the roles page. We're fully allocated for a few quarters getting some large initiatives out the door and will likely see this slated sometime next year. I will update this thread when I have more concrete news about timelines. Appreciate your feedback and helping get this prioritized. 


Please sign in to leave a comment.

Powered by Zendesk