nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How can we really work with Teams?

Ana Vitória Selista_b5kse9

Hy everyone,

I’d like to hear your thoughts on Teams in Atlassian products, especially when it comes to handling teams as data (e.g., using them in fields or as values).

Recently, I worked on a solution for a client who really liked the Teams concept in Jira. However, we ran into several limitations, mostly related to scalability and functionality.

For example, we wanted to create an automation that would trigger actions based on the team a user belongs to. But this turned out to be impossible, since teams can’t be referenced the same way as groups or project roles. There’s no native support for accessing team data across the platform. Of course, if you’re using ScriptRunner or JMWE, you can work around it using the team ID, but if we stick to native Jira features, using teams feels more like a pain than a solution.

Why do we have a functionality that cannot be referenced across products? Is it really just to add people and assign to issues?

I was disappointed to see that there’s no indication Atlassian plans to improve this in the near future.

What’s your experience with Teams so far?

Comments

Anne Saunders

Teams are nice for mentions and kudos but that's about it.

I actually put in a request for more admin control over Team Pages a week ago - we don't use a couple of the tools that have fixed widgets there, so all they do is take up space.

Thanks for raising this! I'm interested to learn if/how others use teams in vanilla jira.

Jeramy

We looked into the "Teams" concept a while back, same reason as you. We wanted automation to trigger based on the team. Jira Data Center (probably Jira Cloud) has a "Teams" function built into Plans (Advanced Road Maps). However, only Jira admins were able to add/remove users and the project lead didn't want to create tickets for me (Jira Administrator) to update these teams as they changed weekly.

I had a few discussions with Atlassian on making Teams more integrated and not require Admin permissions, but both of my tickets were "Closed, not going to do."

My guess is because they'd rather you use an add-on (which there were a few at that time) than for them to deal with that code.

To me, my opinion, Atlassian has gone to a Security-only focus and they leave the "new features" to 3rd party vendors. Which makes sense, they take 30%, someone else does the work and takes the responsibility...

We ended up using ScriptRunner to achieve the "Teams" stuff that we wanted to use.

Good luck.

Nika

Hi Ana,

In my experience, I haven't seen much practical benefit from using the Teams functionality either. One of the challenges is the lack of comprehensive documentation that clearly explains how and where Teams can be effectively used. Because of that, I’ve had to learn mostly by trial and error, and I’d be happy to share what I’ve discovered so far.

Teams can be quite useful for structuring organizations, especially when you start by formally registering teams within Jira and configuring them to be linked with relevant projects, Confluence spaces, and even assigning them to tickets. This becomes particularly helpful in larger organizations.

Here are a few cases where I've found Teams somewhat helpful:

Managing multiple teams in a single project: When several teams work on the same Jira project, you can use team metadata to segment issues, create team-specific boards, and design filters that give each team their own tailored view. This makes large projects much more manageable and improves the overall sprint planning experience.
Visualizing work in Plans (Advanced Roadmaps): Once Teams are defined, you can use them to map out timelines, see who’s working on what, and understand team capacity and workload. It’s not perfect, but it adds a layer of visibility that helps in planning and forecasting.
Automations:I actually see it the other way around — Teams can be used to some extent in Jira’s native automation, but unfortunately, they’re not well supported in most plugins like ScriptRunner or JMWE. So while the native features offer some basic functionality, the lack of broader integration is still limiting.
Integration with Service Management: In the context of incident management (like the old Opsgenie features), you can integrate Teams to help manage on-call schedules, incident ownership, and escalation paths. This has been useful when Teams are aligned with operational responsibilities.
Use across other Atlassian products: You can also make use of Teams in Atlassian Goals, Projects (formerly Atlas), and track team progress across projects, though again, the experience is still not seamless.
Admin-level team management and permissions: It’s also worth noting that on the admin side, there’s potential to convert Teams into groups and manage permissions accordingly. I haven’t personally explored this deeply yet, but it opens up possibilities for access control and governance, especially in larger organizations where structured team-based access is essential.

So while the Teams feature feels limited and underdeveloped, with some creative configuration, it can still bring value and improve productivity in certain contexts. I really hope Atlassian continues to invest in making it more robust and integrated across their ecosystem.

Looking forward to hearing how others are using it too!

Josh McManus

There is some new functionality that I noticed recently that allows an admin to sync a Team to a Group, which means team members can handle user management but you can enable permissions to the group. It does seem a little complicated since it requires a Site Admin to set this up...but it does enable things like tying access to team membership. However my big source of pain at the moment is the wide open access to team creation. We are trying to use the Team concept to structure our organization but the problem comes in that absolutely anyone can create a new Team. This means inevitably we will get duplicates or inaccurate teams and that just makes the list unmanageable. Additionally being able to sort filters based on Team name isn't possible, and there are some pretty critically useful gadgets that don't work with the Team field and require 3rd party apps to accomplish.

Ben Ernest-Jones

We looked into the Teams property but don't use it because you can't assign more than one Team to the field.

We have several Scrum teams, and each one uses their own Jira project / backlog, but across Scrum teams, we have technical teams. The "C++ Team" has members that belong to each Scrum team (the C++ team spans multiple Scrum teams, but each C++ dev only belongs to a single Scrum team). When we do Story refinement / sprint planning, it is useful to know what technologies the Story will require (C++, Java, web, etc) specifically because we want to know who from which technology teams will be required that sprint to work on the Stories of the sprint, which is useful for capacity planning. Indicating that a Story will require: "C++ Team", "Java Team", "Web Team" is useful... but because the Teams field only allows one value, this is not possible.

Rather than introducing a new custom field for this, so far we've decided to cheat and re-use the Component field... in addition to application components, we also indicate "team components" (we created components like TM_CPP, TM_Java, etc).

Alex Young_mdaj1e

I have found basically no use for Teams. They seem to just duplicate functionality of Groups in a lot of ways. I wish Atlassian had just enhanced group functionality instead of creating a whole new construct.

Darryl Lee

Hear hear, @Ana Vitória Selista - great topic.

My opinions are covered by most of the existing responses.

I understand that Teams were designed from the get-go to be ad hoc because they were part of the then new "Team Central/Loop" thing way back in 2021:

But in the real world... we end up with duplicate Teams, people accidentally deleting Teams, and Teams that duplicate existing Groups. What is Source of Truth?

Being the Agile folks that they are, Atlassian of course pivoted and transformed Team Central/Loop (early access trial) into Atlas (paid) into Goals (free?).

In trying to make it part of their Teamwork Collection I suppose somebody realized oh, real companies probably want some kind of control/governance over this feature.

So they introduced Managed Teams:

Managed Teams are now available for Premium and Enterprise customers!

Oh right, this was introduced (IN MARCH 2025) because of feedback:

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

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

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

But then you know, somebody probably eventually realized people have existing IdPs with you know, existing groups, so then there's this EAP (again, not fully released):

Sync team members with SCIM user provisioning

But yeah, god forbid Atlassian give you the ability to restrict the ad hoc teams, because I dunno. Freedom. Agility. Something.

JRACLOUD-81740 - Ability to limit who is able to create a new team and who is able to delete any team [UNRESOLVED]

Matthew Berzinskas

Teams is relatively new, so I'd imagine there will be more features coming if people actually show interest.

However, you can use Teams in Automation by doing referencing the custom field and the team id (without Scriptrunner), your automations are just limited by where you can use the "More Options" section.

But we use simple automations, like assigning issues to a team based on whatever criteria (Request Type, etc).

And they are seemingly building out the REST API for membership interactions:
https://developer.atlassian.com/platform/teams/components/team-public-rest-api/

So if you have a practical example of what you were trying to do that didn't work well, we could maybe discuss further too.

Josh McManus

The issue with the Team field and Automation is that there's no way to trigger off of the field update. Instead you have to trigger off of Work Item Edited which makes the automation run with every issue update, regardless of whether that field is edited or not.

Ana Vitória Selista_b5kse9

Not to mention that Teams are global across the organization, so if you have more than one Jira instance, your teams are shared whether you want it or not.

Ana Vitória Selista_b5kse9

That’s true, there is a lack of documentation, even about API endpoints for Teams.

But I don’t agree with your vision about working with teams in automations. Have you tried? Because there’s nothing you can do. You can’t create conditions about team field, can’t search for members in a team, and the only way you can work with it in the actions is through advanced options, with the team ID.

Really hopping for a better future for this feature!

Ana Vitória Selista_b5kse9

There’s so much going on and at the same time we lack basic ways of working and integrating this functionality.

Matthew Berzinskas

You can trigger off the field update like so: Screenshot 2025-05-14 at 12.11.12 PM.png

However, if you want to get more details about the team, you have to programmatically extract data via a webhook to the API or some other method.

But its still unclear what actually the original poster was trying to do that was not successful, so it may be easier or harder than this.

Josh McManus

Ah right, no you're right on this front. This was a relatively recent development and I forgot that they added this. Totally fair!

Ari Raatikainen

Hi Anne,

To extend what I have used a learned about Jira Teams, it initially sounded like a great concept and supported Atlassian message about System of Work / enabling Technology-driven teams work differently.

In reality Teams "feature" in my opinion is not ready and its been a disappointment. The most ready and useful part of Teams is Operations (ex Opsgenie), alerts / on-call schedule and integrations. In wider Jira context, I feel Teams is not yet mature due to already shared responses. One more specific issue I’ve encountered with the feature's immaturity is the inability to set a Team as an email recipient in an automation rule—a very basic function that is currently not supported.

I hope in near future Team can be used similar to Group.

Gal Fatal

I tried to use team in Jira. but...with no JQL support it's useless for many customers.

The critical missing JQL is "memberOf". (same as in group)

Influential Eliot

Yo, @Josh McManus, I don't suppose you could point to that somewhere, could you?

Knowing this would assist greatly before I ask our admin to create a group! :sweatsmile:

Josh McManus

I wish I could, but alas my research in answering your request has led to further disappointment! Apparently when you create a Managed Team by syncing it to the Atlassian Group, team membership becomes controlled by the Group and users can no longer manage team membership on their own. What a frustrating missed opportunity!

https://support.atlassian.com/atlassian-account/docs/what-is-a-managed-team/

Influential Eliot

Yeah ... it's a bit pants, innit.

Luckily, I found that we already have a group!

Honestly, this system, though.

Michiel SCHUIJER

Hi @Ana Vitória Selista,

Did you make some new discoveries since you posted this?

There's been a lot of development on Teams the past year(s), and it's shaping up, but still there's a lot to improve as well.

I've been wanting to roll this out more completely, but most orgs are running into the issues mentioned by you and others, even though it is now possible to have Team Hierarchies (with visual aid).

The biggest limitations I encountered:

Not possible to limit team creation to just admins/certain people, in case you want to manage them centrally (for example with SCIM groups and have managed teams)
Not possible to assign multiple teams to a work item
Not possible to make the team field mandatory
Not possible to do proper JQL on the members of a team
Limited automations still

I do hope Atlassian keeps improving it, and I think they will, but if it's fast enough to everyone's liking and can keep up with demands and competitors?

Honestly, I don't know of any good alternatives either, that can deal with this, unless maybe (big IF) your entire org incorporates Slack (with business+ or enterprise plan) to properly automate, administrate and manage things. Maybe other people have more insight into it, or someone will jump in this gap?

Josh McManus

One further limitation that I ran into was "archiving" teams. For things like Versions, you can Release/Archive versions to prevent them from populating the pick list in Fix Version, but there's no similar function for Teams. However, what happens to Jira issues assigned to a Team when a Team gets deleted? For completed issues we can't lose the historical data because we need to know the history of which team completed the work, but we also don't want an ever-growing list of Teams to pick from as our organization evolves. I have a short-term workaround I'm implementing for this where Automation will update a Text field with the currently assigned Team name when an issue is closed, but I'm not very excited about it.

Michiel SCHUIJER

@Josh McManus it's like they're listening to you: https://community.atlassian.com/forums/Atlassian-Teams-User-Group/Archive-Teams-Keep-your-workspace-clean-without-losing-your/ba-p/3151635

Archiving teams has arrived!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-cloud

teams