What's the best way to use JIRA project roles versus groups for permissions?

Hey everyone, I’m a bit confused about JIRA permissions. I can’t quite figure out when to use groups and when to use project roles. I’ve looked at the docs, but it’s still not super clear.

Here’s what I understand so far:

  • Groups: You put users in a bucket and give that bucket permissions.
  • Project roles: Similar to groups, but you can add groups to them and project admins can add users.

I’m trying to set up JIRA for my company where:

  1. We have multiple projects
  2. Our staff have the same permissions across all projects
  3. Clients can only see their own projects

I’m thinking of doing it like this:

  1. Make an ‘employees’ group for our staff
  2. Create project roles for clients
  3. Set up permissions using the employees group
  4. Copy and tweak permissions for client projects

But I feel like I’m missing something about project role membership. Can anyone explain when and how to use project roles versus groups? What’s the best practice here?

Thanks for any help!

In my experience, your approach is on the right track. Groups are indeed more suitable for company-wide permissions, while project roles excel at project-specific access control. For your scenario, I’d suggest creating an ‘Employees’ group with baseline permissions across all projects. Then, set up a ‘Client’ project role for each client project. This allows you to easily manage client access without affecting your staff’s permissions. One key advantage of project roles is that project admins can manage them without needing system-wide admin rights, which can be particularly useful as your JIRA instance grows. Remember to regularly audit your permissions structure to ensure it stays aligned with your organizational needs as they evolve.

I’ve been using JIRA for years, and I’ve found that a hybrid approach works best. Here’s what I do:

Use groups for broad, organization-wide permissions. Create an ‘Employees’ group with base-level access across all projects. This simplifies managing staff permissions.

For clients, leverage project roles. Create a ‘Client’ role for each project. This allows fine-grained control without affecting employee access.

The real power comes from combining them. Assign your ‘Employees’ group to a ‘Staff’ project role in each project. This way, you can tweak permissions at the project level if needed, without messing with the global group settings.

One tip: use scheme sharing for similar projects to reduce admin overhead. It’s a game-changer for consistency and saves tons of time.

Remember, there’s no one-size-fits-all. Adjust as you go based on your specific needs and workflow.

i think project roles work best for prject-specific perms while groups are good for overall access. use an employee group for general access and set up roles to control client view. this way you get the right mix of ease and flexibility. hope this helps.