How can we really work with Teams?

[Ana Vitória Selista]

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?

[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. :)

[Ana Vitória Selista]

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.

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

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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!

[Ana Vitória Selista]

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!

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

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:

• Introducing the Loop: A framework for predictable comms in an unpredictable world 
• Team Central Demo 

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:

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.

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]

[Ana Vitória Selista]

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

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

[Matthew Berzinskas]

You can trigger off the field update like so:

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!

[Matthew Berzinskas]

Thats part of the reason Im optimistic that they are leaning into Teams. Seems to be a lot of momentum behind tying everything to Home/Teams/Goals/etc.

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