How to configure Non official Teams and add restrictions on members

[Tess Doris]

Here is the scenario:

All spaces in Jira are private and can not be searched by folks not assigned to the space authentication group. All spaces are company-managed. 

We control permissions by assigning the Authentication group to the team member role.  The update permission scheme then uses the team role for permissions. 

Now we want to set up the team and remove team members' access to add/remove or change details. They don't want to use Official Teams as this then puts the overhead on the admin to maintain the teams, and they change frequently.   

From the article below, it states in part, "Users must have Browse Users and Groups global permission before they can add members or make changes to a team."

I removed any_user and replaces with Groups and set it up as group-specific. 

Browse users and groups View and select users or groups from the user picker, and share issues. Users with this permission can see the names of all users and groups on your site.

 This issue is now that I have this set up, even though I am part of the group with access, 

When I try to add people, it says they do not have access  

"We can’t add xxxThey may not have access to teams in your organization".

So that means if they are not in the group, they can't be added?  

Any suggestin on how to make this work correctly? 

https://support.atlassian.com/platform-experiences/docs/start-an-atlassian-team/

[Cristian Quiroz]

Hi @Tess Doris

The challenge you're hitting is a known limitation; according to the official docs:

"Once your team has been created, organization admins, user access admins, and team members will have the same permissions."

So with the default team type, there's no way to restrict individual members from adding/removing others. The Browse Users and Groups workaround unfortunately creates the side effect you experienced, users outside the group become "invisible" and can't be added to teams at all.

The cleanest solution that avoids the admin overhead you mentioned is to use Custom Team Types + Delegated Permissions:

• Create a custom team type (e.g., "Project Teams") by design, all newly created team types are admin-managed and verified, meaning regular members cannot modify membership or settings. See: What are team types?
• Use Delegate permissions for team types to grant specific people (e.g., team leads) the ability to manage teams of that type, without making them org admins. See: Delegate permissions for team types

This way:

• Regular members cannot add/remove members or change team details
• Designated team leads can manage teams without being org admins
• No need to touch Browse Users and Groups, revert it back to any_user to fix your current issue

Hope that helps!