Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Defining group membership for users is lots of work. Anyway to make it simpler?

Hello there,

I am asking this question on behalf of one of my customers.

They are using JIRA, Confluence integrated with Crowd. They have apporoximately 2,000 users and each user belongs to his/her department.

Their Crowd uses "delegated authentication" i.e. username and password comes from LDAP, but group memberships are defined in Crowd.

Now, there are lots of groups within Crowd, and it takes some effort to assign all the necessary group membership to a user each time they add a user.

I asked them to consider reducing the number of groups, but they said it is not possible because their Confluence spaces need access control in accordance with each groups, and the number of their Confluence spaces are rather large, requiring different set of access control.

Is there any way they can simplify their process?

Any ideas greatly appreciated.

3 answers

1 accepted

1 vote
Answer accepted

Pretty much what you've already said - cut down the groups. If they don't want to do that, then they need to accept that they're going to have a lot of work maintaining them.

I think it's worth asking them how they think they'd like to "simplify" it - could they use a small number of generic groups and maintain individual space users? Is the Crowd interface the issue? Are they doing the same thing every time and you should look into scripting/templating?

Find out what they think would be more simple, and work from there. It's hard to deal with "it's too complex" when you don't know wha they think the complexity is...

I think that one major problem with groups is the inability to rename them and to assign descriptions and an owner to them. Adding this would enable people to manage them.

Yup, completely agree, although I've looked at the possibility of renaming groups in the code, and it's a lot nastier than it sounds to implement. I can understand the resounding silence from Atlassian on that - it's not a minor tweak. Descriptions would be quite easy though.

Hello All,

Thank you for your respective answers.

Let's think about Confluence. Suppose your organization have 50 departments, and each department has 30 staff.

You create a Confluence space which can be accessed by only your department and one different department. Let's assume all departments have similar requirement.

In this scneario, you would probably have to create 50 different groups, and assign them to 1,500 different users in Crowd.

Isn't this a lot of work? Anything can be done about it?

I can't see any way around it. If you want to use a separate group for each department, then you've got to maintain it somehow.

I'd be asking the question "do we really need this level of segregation in our applications". If the answer is yes, then there is no way to do this more easily - you've got a mass of data, you need to maintain it. There's no way to simplify it because your users have decided they need the complex mass of data.

Personally, I push this on to the space/project owners. In Jira, use roles, then the project admins can add individuals. In Confluence, the project admins can add individuals. If they think this becomes too painful for them, then explain the scale of the problem with group maintenance and get it recognised as a business problem.

From one experience with a Jira/Confluence install - 20,000 users, two main business units (split was roughly 8k/12k). Within each unit, there are hundreds of groups.

I maintained all the groups for the larger unit - in the sense that I'd set up a handful (6ish) of groups that really did need to be groups, and all the projects used roles for most of the access. Project owners were responsible for users in their areas.

The other group hired two full time group administrators doing *nothing* else because they didn't want to delegate the group maintenance to the project owners.

Short answer - talk to your users and get them to think about group maintenance properly, as a business problem.

Get groups from LDAP mailing lists, but filter them and use a special mailinglist that has to include the other mailing list that are supposed to appear in Jira/Crowd/Confluence.

People in need of groups should ask IT for a new mailing list, which has to be added as a member of your mailing list.

Doing this you, the Jira admin, will externalize the group managment to the IT.

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events