I’m trying to figure out the best way to set up permissions in JIRA and I’m confused about when to use groups versus project roles. The documentation explains both but I still don’t get the practical differences.
From what I understand, groups work like this: you put users in a named group, then assign that group to permissions in a permission scheme, and finally apply that scheme to projects. Project roles seem to do the same thing but you can also add groups to them. Plus project admins can manage users in roles without needing system admin access.
Here’s my situation:
We have several projects in JIRA
All our internal staff (managers, devs, etc) need the same access across every project
Each client should only see their own project
My current plan is to create an “internal-staff” group for employees and separate project roles for each client. Then use the default permission scheme for staff permissions and create custom schemes for client projects.
But I feel like I’m missing something about how project role membership actually works. Can someone explain the key differences and what the recommended approach is for this kind of setup?
Project role membership trips up most people. When you assign someone to a project role, it only applies to that specific project - not everywhere. So if John needs access to three client projects, you’d add him to each project’s role separately.
I’d stick with your original plan here. Create your internal-staff group and use it across all projects where employees need access. For clients, make individual groups per client instead of using project roles directly. Way easier to maintain - when a client contact leaves, just swap them in the group instead of hunting through tons of project assignments.
Project roles work best when you’ve got different access levels in the same project. Like developer vs QA vs project manager roles. Groups are better for stuff like internal vs external users.
One heads up: project roles can pull permissions from multiple places, which makes fixing access problems way more complicated than basic group permissions.
The biggest pain with JIRA permissions isn’t understanding groups vs roles - it’s keeping them updated as you grow.
I’ve been through this at several companies. Managing permissions manually becomes hell when you’re constantly adding projects, clients, and team members.
Your setup sounds good, but think 6 months ahead. New clients, staff turnover, permission requests. You’ll waste hours each week on JIRA admin instead of actual work.
I automated this whole mess with Latenode. It hooks into JIRA’s API and handles group memberships, project roles, and permission schemes automatically using data from our HR system and client forms.
New client? Latenode creates the group, sets up the project with proper permissions, and assigns roles. New hires get added to internal-staff based on their department in HRIS.
Runs daily to sync changes. Haven’t touched permissions manually in months.
Set up your groups and roles whatever way works now. Just automate the upkeep before it eats your time.
You’re missing a key difference: project roles only work within specific projects, while groups work across your entire JIRA instance. Assign someone to a project role? They only get that role in that one project. Groups apply everywhere they’re used.
I’d flip your approach. Use groups for both internal staff AND clients, then add project roles as another layer. Keep your ‘internal-staff’ group, but also make client-specific ones like ‘client-abc’ and ‘client-xyz’. Then create project roles like ‘External Users’ or ‘Client Access’ and add the right client group to that role in each project.
This scales way better. When you add new projects, you don’t have to rebuild all your permission logic - just assign existing groups to the right project roles. JIRA checks project role membership for permissions, but using groups underneath makes admin work much cleaner long-term.