Atlassian teams are coming to Jira Software!

[Rick Westbrock]

Great recap and it really reinforces that this new feature is half-baked at best (maybe less?) as most places that customers want to use it are not supported.

[Gregory Kremer]

@Rick Westbrock Sorry to say, but it wasn't half-backed, in my honest opinion. Atlassian people were well aware of no benefit to the users from this change. They did it to simplify the maintenance of the Team field, because prior to it they needed to do it in 2 places - Advanced Road Map and Team collaboration. Unfortunately, they did it to the detriment of their users/customers. That would have never happened 10-15 years ago, when Atlassian was still a young, customer oriented company. But the minute they became established and had their customers deeply sucked in into using their apps, they became like any other large software company - more concerned about being profitable (I don't blame them for that) and less concerned about their customers (I do blame them for that).

[Adam Gustafsson]

I think it's a big flaw that it's not possible to assign multiple teams to at least initiatives or other high-level "container". Usually an initiative will involve a lot of different people in the organisation, and thus it does not make sense to only assign one team. 

I do understand that you can create a team for each initiative, but that require people to remember who is included in each team and it won't be easy to get an overview in e.g. Jira Plans if you need to figure out who is in what team first. 

We have both tech teams but also business functions such as operations, finance etc. It would be very good if it's possible to assign these to one issue (at least on a higher level, such as initiative). The whole thought behind Jira Plans is to be able to get an overview, but by not being able to chose multiple teams I think it does not fulfil it's true potential. :/ 

[Calvin]

Certainly looks interesting, had a few question on it however.

In your documentation at: https://support.atlassian.com/atlassian-account/docs/what-is-an-atlassian-team/ you say:

Assign issues to a team in Jira Software, Jira Work Management, and Jira Service Management

But it doesn't seem like you can assign to a team at all as the assignee field still is a single user and this is instead another field?

If so is there any "ways of working" regarding assignee vs team. Like does the team own the ticket now, does the assignee own the ticket now, are they notified when assigned?

Also in enterprise is teams shared across the whole enterprise? So if I wanted an Atlassian team for a few users, they could still be emailed/assigned to an issue on another Atlassian product in a completely different part of the business (or even country)? And anyone with Jira admin can create a team so there could be hundreds to choose from if you have many instances?

Apologies, its super interesting stuff but also interesting how they affect each other.

[Dirk Ronsmans]

I honestly prefer a separate Team and Assignee field. If you start combining them the overview will become utter chaos imho.

The way it is right now you can first assign to a Team and then have the team take care of the assignment within their own structure. 

I get that this is siloed thinking but we have to be honest, especially in a Service Management environment this is still the way of working.

Issue comes in -> triage -> assign to 2nd/3rd line team -> have that team do their own assignment to a person with the expertise (or who has availability)

Ownership at a whole is something different again (talking JSM here) where I feel that the team that did the intake and communicates with the end user should remain owner and perform follow up/chasing of the issue.

When it comes to assignment within the team that falls to the Team the issue is assigned to.

(just my thoughts :))

[Calvin]

Thanks Dirk, for the above:

I honestly prefer a separate Team and Assignee field. If you start combining them the overview will become utter chaos imho.

I'm okay with either direction but the documentation link makes it a tad confusing. Guaranteed if I tell anyone to "assign that ticket to a team" or as per the documentation "you can assign tickets to a team" they will go to the assignee field and try to find the team.

Instead of going to the team field, adding the team in and unassigning themself. TBH the team field feels more of a field to say what team the ticket is a part of instead of assigning.

Don't get me wrong, I really like this feature haha I'm just getting my head around how its laid out (or maybe I just need to rename it "Team Assignee:").

The way it is right now you can first........

YES to all this haha. So much so I think you made the best official 'ways of working' for using Atlassian Teams :D.

[David Meredith]

I know that the main driver here is to consolidate the Teams / Plans team functionality but the marketing I've seen describes it as something that can be used for assigning to teams and honestly I feel like it still falls short of even doing that.

I mentioned this a while back in the comments but the workarounds we've been using to achieve team assignment are still more practical and usable than what has been delivered here.

There are drawbacks, but using a custom field to store a selected group as an assignment group means that we can limit the assignee to members of that group by adding the custom field to the Assignable User permission in projects.

So if you assign to the 'Networks Team', the Assignee can only be a member of that group. Automation rules assign the groups to the custom group field so the user doesn't see the mess of groups in the backend, increments handy metrics like Assignment Count and if the assignee isn't a member of the group that's been assigned, unassigns them. Then 'Networks Team' can assign to the relevant person.

This is generally the implementation that you find in other ITSM toolsets and it can be achieved really easily here.

I'd like to use what Atlassian is building around Teams but currently it's just not as good as groups as you have the added benefit of :

• Syncing with IDP
• Controlled by admin for user membership
• Used to include multiple groups (not for assignment)
• Used in automation rules
• Used in project roles
• Used in project permissions
• Used in workflow

[Sebastian Wramba]

Is the documentation ahead of time? Neither within the project nor in the global issue search, the Team dropdown is supported.

[Todd Thomas]

Great summary of the issue here, Adam. I'm hoping Atlassian recognizes that this new feature really needs more versatility and flexibility to create value for their customers.

[Haddon Fisher]

Team Field

I'll add my voice to the throngs, but I'll maybe go one step further:

We should be able to create single and multi-picker team custom fields like we can for users and should be able to do for projects.

Initiatives have been called out a couple of times above; one of the main reasons the entire "initiative" concept was created was to facilitate big chunks of work which in all likelihood entails multiple teams coming together.

"Incidents" is another example; it's pretty common for ownership of incidents to be initially murky, and so incident managers would need a couple of teams to weigh in.

In both of these situations I could see needing to report on things like "What Team Reported This", "What Development Teams Looked At It", and\or "What Development Teams Actually Did Work To Deliver This". The easiest way I can think of to solve this would be a combination of Automation and some custom team fields.

Team Creation\Management

There absolutely needs to be some controls or metadata around this - ideally, we'd be able to differentiate teams as being "something created by a user" or "an actual officially recognized org unit". If we have to prevent people from creating teams, we're losing a decent chunk of the potential value with the entire concept.

[Aleksandr 2easy]

Hi.

1. How we can add Team field to Issue security scheme? So that when we add any team, it opens view access to the ticket. I cannot find Team field to add it to issue security level.
2. What's about notifications? When we adding any Team to the ticket, they will be notified about that? What notifications is working for all Team collaborators?

[Gary Spross]

@Aleksandr 2easy, I asked the same question about notifications earlier in this thread and this was the response I received. Really hoping Atlassian can get notification for Teams implemented soon. Otherwise, this field feels kind of worthless...

[Efe Obaseki]

CAN THE CUSTOMFIELD BE USED WHEN ONE IS ON A FREE PLAN?

[Darrel Jackson]

One tip for anyone who uses sandboxes as a pre-production staging environment and already use the Team field.

This change won't migrate Shared Teams until the production site is migrated. So if you've taken the change in to sandbox but not production, it will look weird. Basically, the Team assignments will be retained but you won't be able to select any Shared Teams if you edit the field.

One your production site is migrated, the sandbox will look fine.

Just thought I'd let people know as I freaked out when it didn't work in sandbox.

[Yerbol Nisanbayev]

Teams field is available to all plans, including the free plans

[Aleksandr 2easy]

@Gary Spross Tnx.

Maybe u additionally know about:

1. How we can add Team field to Issue security scheme? So that when we add any team, it opens view access to the ticket. I cannot find Team field to add it to issue security level.

?

[Gary Spross]

@Aleksandr 2easy, I don't know the answer to that question. As the Team field functionality is still being built, I'd hope this is something that Atlassian would get to, but I don't know as I have not found any sort of roadmap from them.

Currently, the Team field is only useful for searching for related issues. You can then show those issues in a dashboard gadget. As far as I'm aware, that really the only usability for the field. In my opinion, until things like notifications and issue security schemes support the use of this field, it's not really much help.

[Haddon Fisher]

Hey Yerbol Nisanbayev, first, I love the engagement here. Feels so nice!

Second, you said in a previous comment:

Teams are different from groups as groups are admin controlled and are very strictly managed, usually used for permissions. Teams are meant for collaboration and can be created by any users

Is this the "official" way Atlassian is thinking about 'teams' and how they will be different from 'groups'? I'm asking because I was really hoping that we would eventually be able to hang permissions off of them in all of the ways we can right now with groups.

As you said, "Groups" are only maintainable by site admins, which makes them pretty unsuitable for most things. Having user-managed teams which they can then put their Confluence page or Jira assignable permissions on would actually be a great value-add...users have a 'group' concept they can use, and admins can stop managing groups and/or telling users that groups aren't a thing.

[Marc]

Is there any API available to get available teams for the Teams Field when editing issues via REST API?

I would've expected something in the response of "/rest/api/3/issue/{issueId}/editmeta", but all we get is an autocomplete URL which I haven't been able to get to work in our app. 

[Yerbol Nisanbayev]

Hi @Marc 

We do have a REST API for teams, please find more info here

https://developer.atlassian.com/platform/teams/components/team-public-rest-api/ 

[Yerbol Nisanbayev]

Hey @Haddon Fisher 

You can read more about Atlassian teams here https://support.atlassian.com/atlassian-account/docs/what-is-an-atlassian-team/ 

In short this is how teams work today, but our idea of teams is evolving in large part thanks to the feedback that our customers share with us.  We do hear from our customers that Teams need to be available in permissions, especially in products like Confluence. So we are in early stages of looking at how we could make teams available in permission schemes, just like groups are today.

Thank you for your input, it would help us further prioritise the permission work among other things we are working on 👍🏼

Please watch and vote on this ticket, that tracks this specific feature request: https://jira.atlassian.com/browse/JRACLOUD-80976 

[M Amine]

Hi @Yerbol Nisanbayev 

Can this Team field be used for Jira Align integration? If not, is Atlassian planning to work on this? 

Thank you

[Younes Abou Khzam]

Hello, 

Adding my voice to the three following ideas:

- Ability to have a multi-team picker custom field, so that we can add multiple departments to action on an issue

- Ability to get notifications (ideally also in the MS Teams bot), based on the Team field. Currently we have to automate watching on a ticket so that multiple people get notified, especially in Jira WM/Software projects. We do want the team handling the ticket to get notified of its creation for example, without having to spam their mailboxes, and the Teams bot offers that direct notification feature handily.

- Consolidation of Atlassian Teams and directory groups so that they are streamlined without having to duplicate them (we use groups in permission schemes and teams for mentions)

[Rik de Valk]

Hi @Yerbol Nisanbayev , 

For Jira Service Management it would be high value to be able to use Teams as Attribute type. 

This will enable organizations to map Teams to Configuration Items (Assets) in their CMDB. This will allow them to automatically assign issues based on the selected CI on Incidents, Service Requests. 

Obviously, this is closely related to the Services feature. The docs on Services currently states

'Bringing services and objects closer to work together smoothly is a priority for future development cycles.'

It would be good for the product teams in Atlassian responsible for Services, Assets and Teams closely align on how the Teams-Services-Assets work together. 

[Colin Minihan]

The team search is lacking. I would like to search for any ticket created by a member of a Team. Or assigned to any member of a Team. Similar to memberOf([group]). This functionality would make defining teams very useful. At present, it's lacking.