Teams vs Groups in the Atlassian platform - how can we improve?

The concept of groups as a way to bundle people together has been around in the Atlassian platform forever. Teams is a newer concept, and it is not designed for the same purpose as groups. As the group functionality regressed into a black hole of no visibility and poorly defined offboarding processes, which has led to security issues I think it is time to review the situation.

Groups and the black holes in the Atlassian platform

I have talked about this many times. Groups that are managed only in the Atlassian platform are a nightmare. Every Data Center installation knows the agony of cleaning groups and the dysfunction of having a platform that is detached from the global user management. It does not matter how much time you spend micromanaging your groups if you have not connected the offboarding process to include the Atlassian platform. Which, no one does for some reason...

If you have a dedicated Atlassian team managing access through groups, and even if you have the best offboarding process where the team is actually getting tasks when someone offboards, you will still have problems. No matter how well you organise things as an Atlassian admin, you can never know where or how your well-pruned groups will be used. Any space admin can add any group at any time to do anything they see fit. But they have no idea who they are providing access to...

That is the curse of the group function:

• Only Atlassian Admins can see who is in a group (no visibility)

• Users can add groups anywhere (no visibility)

In the most common scenario, the Atlassian platform team does not get informed when a user is offboarded, and no one documents groups, so they know why they exist or where they are being used. As a result, almost all Atlassian platforms will have people who are no longer working in an organization that have an account that they can log in with that gives them access to areas no one really knows they have access to.

More than one Atlassian platform has had security incidents because of this...

What about Teams?

Teams started as a local group inside of what is now Plans, which you still can do for some reason. It has since evolved a bit, and after a few years of Atlassian playing around with the concept, it is now in this weird state where it is conceptually broken. In theory, teams are a better implementation than groups, simply because they have visibility and team members can manage who is on the team themselves. This would hand the responsibility to the people who actually own people management and not to administrators.

We now have a Teams system field, and recently we got some automations based on Teams. Of course, Atlassian also focused on changing the color of the Teams icon in a very limited way, which no one asked for, as we want to set Team icons ourselves, but that is where Atlassian is right now. They seem ignorant of the bigger issue, or they just have not figured out how to solve it yet. To be fair, Atlassian has made some changes, but they are slow and seem to lack an overall plan.

One major issue was that Teams where organization wide objects. This was a big issue for organisations that had multiple sites, and Atlassian got a lot of backlash for it. In July 2025, a change started to roll out that changed this, so Teams were localised on the organisation level. This was a big improvement, and with the addition of Managed teams announced in March 202,5 teams seemed to be on the right track. Managed teams are basically synced groups from another system, such as an Active Directory, making the teams sync members automatically.

The reason Atlassian added the Managed Teams made many of us older Atlassian administrators chuckle a bit:

Why did we build this?

Your feedback was a big factor in this, as we heard from multiple organizations that were encountering these challenges:

1. Having to manually create large Teams despite team structure existing in an external source already.

2. Having to manually update Teams, which is unsustainable due to frequent reorganizations and employees joining or leaving.

3. The risk of end users inadvertently connecting an 'unofficial’ Team to work used in critical reporting workflows.

Managed Teams are kept up-to-date with the connected group and remove the friction in keeping teams accurate and updated.

For the past 20 years, Atlassian has not changed groups, even though they suffer from the same problems as listed here. And then some...

With managed teams, regular teams, and local teams in certain products, Teams is a bit all over the place still. To make things worse, there are certain aspects of Teams that you would think would have been considered on day one when conceptualising the feature. Things like that, Team Names have to be unique (?!), or that they can be used across the platform, the way groups can. Today, Teams is pretty useless in terms of access management or as a filtering option, which is why most organisations just don't see any value in it.

There is also the fact that Atlassian keeps changing Teams, and Managed teams are sometimes referred to as Official Teams now. Atlassian is also very bad at describing Teamsand you can see this text, for example, on their official Teams App page:

What is the difference between a team and a group?

Groups are an admin‑managed way to control access and permissions. They’re used to determine who can log in to which Atlassian apps and who can view or edit specific content.

Teams can be created by any user and are used to represent working groups like squads, departments, or project teams. Forming a team makes it easier to collaborate and understand who is doing what, without changing who has access to products or content.

This does not align with the Managed groups, or Official groups, as they sometimes call them. This kind of inconsistency causes confusion, and it happens all the time these days as Atlassian is rapidly prototyping its way to the new vision they have for the Atlassian platform. I also noticed that there is something called Team Types now, which I have never even heard about...

How can we take Teams to the next level, and what about groups?

In my opionion Atlassian should make a decision on what Teams and Groups are. Today, groups are not a good solution for any form of security because of the way groups are managed, or rather, not being managed. I suppose the idea was to follow how other platforms use groups, like for example SAP, but that is not how groups are set up or used in the Atlassian platform. In the Atlassian platform, groups are used as categories for teams that are too lazy to manage the people they work with, or that have set up monolithic spaces where way too many people work.

Teams lack a commonality across all products, which is a problem in general for the Atlassian products, as there seems to be no perceivable holistic plan. Simple concepts like naming conflicts and that Teams can be used across the Atlassian platform should be a high priority, but it seems that they are less focused on the architecture and more on the presentation. I do not know if someone is trying to push the Atlassian platform towards a social network or what the reason is for having elaborate Team presentations, but I would put more effort into the way we can use Teams instead.

Step 1 - New Architecture change for Teams

The first thing to do, in my opinion, is to remove all local Team references and only use the Team app in all products. Only use user-defined groups and Managed groups (just remove the Official designation, it just sounds weird). Restrict user-defined teams to spaces so they can not extend outside of the space scope. Only allow Managed Teams to be used across all spaces. This way, space admins can group their user base if needed, and it can be used to assign Team leaders who manage users in their team. Add a new permission for this so Team managers can add and remove users to the space and assign roles to them (possibly add an approval step from the Admin for better security). This will also prevent duplicate names, as any conflict of names would only occur inside a single space, as it only exists there.

• Managed Teams are the default object. Skipp Official Teams nomenclature.

• User Managed Teams are local objects in Spaces only. Rename to Local Teams

• Add Permission to manage Local teams to assign Space Roles.

  • Add an approval function for approving additions to the Space roles.

• When creating Local Teams in Plans, for example, treat the Plan as a Space or fetch from the Spaces included in the Plan.

Step 2 - Make Teams usable everywhere

The second thing to do is to make sure Teams can be used everywhere. Dashboards, Filters, JQL, approvals... everywhere where you have Groups today. This so you can remove Groups from those areas completely. Add a multiselect Teams field so more than one Team can be connected to a work item (for larger objects like projects and initiatives). Add a functionality under access in each space to restrict the assignment field to the Managed Teams that have been assigned to the space. For JSM, you might also want to add a set of restrictions based on Managed Teams for things like who you can add to a ticket or who can submit tickets. This would act as an organisation, but for internal users.

• Add Teams to replace all features that today use groups (workflows, dashboards, JQL...)

• Add a Multiselect Team System field for scenarios where multiple teams need to be assigned

• Add Space configuration to restrict assignment to Managed Fields assigned to the Project

• Add Spave configuration for JSM, restricting ticket creation or Ticket assignment for participants

Step 3 - Change Groups to become Security Groups

The third step is to remove functionality for groups to be used in filters, approvals or assignments. This should all be handled by Managed Teams now, making groups obsolete for this purpose. Instead, groups are re-defined as security groups that are used ONLY for security configuration in the Atlassian Admin section. This includes application access, global permissions and so on. These security groups are either synced or manually handled as part of the onboarding/offboarding process.

This will make a full separation between the platform security and the user management layer, ensuring that no one adds a security group to a space by accident. It also transitions user management to the Spaces and provides better and easier space management for user access. This should clarify responsibilities, which, at the moment, are very unclear regarding who is responsible for managing groups. Separating in this way will mean that Atlassian administrators are responsible for security groups and the creation of the managed Teams. Everything else is on the teams themselves and the Space owners, as it should be. In the best scenario, an Atlassian admin would have no responsibility beyond the configuration, as the users and Teams would be synced from other systems.

If done correctly, the workflow restrictions could allow Local Teams, which would then allow each space to manage that permission by creating Local Teams matching the name in the restriction. This would allow for easy management, and with proper governance, it can reduce the need for customisation without compromising access control.

Just my initial thoughts

These are just my initial thoughts, and obviously, a proper strategy for the Teams and Groups architecture should be formulated in far greater detail than this. I am sure there are many more ways to improve the Teams functionality and how to rework the black holes that are groups today. These are my suggestions on the subject, but I would love to hear what your thoughts are.

What are your thoughts on how we can better use Teams, and how do you see Groups in the future?