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/

[Andrey - Guenov Labs]

Hi Tess — the error you're hitting is a direct side effect of the change you made, and I think the lever is the wrong one for what you're trying to achieve.

Why the picker broke. Browse users and groups controls visibility, not edit rights. It decides who can be seen and selected in any user picker across the site. Once you narrowed it from any_user to a specific group, everyone outside that group became invisible — including to the team member picker, which is why you get "We can't add xxx. They may not have access to teams in your organization." Worth knowing before you leave it in place: that same permission also governs the assignee picker, @mention autocomplete, request participants and the share dialog, so narrowing it tends to produce a trickle of confusing bug reports for weeks. I'd revert it to any_user.

The bigger point — team membership probably isn't your access risk. Atlassian teams are an organisation-level object. They're independent of a company-managed project's permission scheme unless you've explicitly granted permissions to a team in that scheme. You described your model as: authentication group → team member role → permission scheme. If that's a project role (not an Atlassian team), then people joining or leaving an Atlassian team grants them nothing at all, and policing team membership is cosmetic — you can let it stay self-service without any exposure.

Worth confirming before you build anything: Project settings → Permissions, and check whether each grant reads Group, Project role, or Team. If nothing says Team, you're already safe.

If some grants are team-based, that's the thing I'd change rather than locking the teams down. Move those grants to groups (or project roles populated from groups), and let teams stay open and self-managed for capacity, assignment and reporting. That gives you what your stakeholders actually asked for: churn in team membership costs the admin nothing, and it can't leak access.

If you genuinely do need locked membership, then custom team types plus delegated permissions is the supported route — new team types are admin-managed and verified by default, so regular members can't change membership. Just go in with eyes open that this doesn't remove admin overhead, it relocates it: someone still has to be the delegate for each team type, and you'll be fielding the requests when teams change. That's the trade-off worth putting in front of the people who said they didn't want Official Teams — they may find self-service teams plus group-based permissions is the answer they actually wanted.

[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!