Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
Next:
badges earned

Your Points Tracker
Challenges
Leaderboard
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Recognition
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Kudos
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Best practices for setting up Groups (types and number of groups)

Hi Everyone,

We are in the process of refining our Groups in Jira admin and I've been researching online best practices, but have had no luck finding what I need. I'm hoping the Atlassian Community can help.

The reason we are refining our Groups is because we are wanting to open up Jira projects to visible to more people in our organization while at the same time limiting some visibility for some projects (through using schemes).

We have some people who want to set-up the groups similar to below:

* Role

* Role - Country

* Role - Country - State

* Role - Country - State - City

or

* Department

* Department - Country

* Department - Country - State

* Department - Country - State - City

So most people will be in five groups (default is jira-users) and we'd have to have permission schemes to accommodate the different role/department, country, state, and city of each group. That in itself gives me a headache.

The argument for doing this is that they feel people in some areas should have access to projects in only those areas. But of course, our projects span many geographic areas (we have almost 30 locations in 15 countries). 

What I'm interested in is how other organizations have set-up their groups and if there are any best practices resources. 

Thank you!

2 answers

1 accepted

0 votes
Answer accepted
Chris Boyd Atlassian Team Jun 08, 2021

Christel, 

 

The community here may share with you best practices from their perspective, but I'd like to share you my thoughts from the Jira side of things.  It appears what you're trying to accomplish is this (forgive me if this oversimplifying):

  • Limit project permissions based on the user's geographic location

From your given scenario, indeed the headache would come from the sheer scale of admin work needed to manage all the project permission schemes for all the potential groups you'd have to come up with!

To help come up with a better plan, consider the following from the Jira docs (again, please forgive the simplification):

  • Groups are for organizing users together who should have the same permissions.
  • Project roles are for associating a project function (example: editing an issue) to a user or group of users.
  • Permission schemes are used so you only have to match these groups to their project roles once.  After that, you can apply the permission scheme to multiple projects.

So my recommendation as you plan this out, consider an approach of top down from project down to users:

  • In the permission scheme, match the role to the permission, not the group.
  • Apply this permission scheme to all the projects you need it on.
  • Associate the appropriate groups to the roles.

In that way, all the work left is putting the users in the correct groups, and going forward when users come and go, all you have to do is manage which users are in which group.

Again, this is very oversimplified, if the problem is too complex you may want to wait for the community to chime in, or perhaps seek out a consultant.

Good luck!

Hi @Christel Gray ,

I would use the combination of both groups and jira project roles in the permission scheme.

Create a user group with Department - Country - State and provide browse project permissions or use it in the issue security level scheme (as per your requirement).

Then add users to project role. By adding the group as a project role you cannot differentiate between the level of access. 

For instance, if you have an project administrator and developer from the same Department - Country - State, you can provide browse project permissions to the group so that they can view the project issues and different permissions for the administrator and developer.

This is just a high level idea and you can still narrow it down based on the use case. 

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PERMISSIONS LEVEL
Site Admin
TAGS
Community showcase
Published in Jira Service Management

JSM June Challenge #2: Share how your business teams became ITSM rockstars

For JSM June Challenge #2, share how your non-technical teams like HR, legal, marketing, finance, and beyond started using Jira Service Management! Tell us: Did they ask to start using it or...

322 views 9 7
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you