SCIM-synced Teams EAP - New and upcoming features

[#1]

Hi everyone

My name is April and I’m a product manager looking after Atlassian Teams. Thank you for participating in our EAP and for all the feedback.

Here are some updates from my side on this SCIM-synced Teams EAP.

---

🎉 Introducing a new configuration called Managed Team

We launched SCIM-synced Teams early to get feedback from you. SCIM-synced Teams is a part of our new team configuration called Managed Teams.

What are Managed Teams?

Managed Teams are Atlassian Teams that can be connected to groups, which serve as the source of truth for membership. You have the option to connect either an externally managed group or a local Atlassian group. Features include:

• It can only be created and deleted by organization admins in Atlassian Administration

• The connected group acts as the source of truth. This means:

  • Membership will be synced with the connected group

  • Team name will be derived from the group, however, org admins have the ability to rename this in the team profile.

• A Managed Team can be identified by a indicator in work

---

💫 Managed Teams: Upcoming features

**Some of these timelines may change and the actual feature may look different to the mockups. I will keep you all up to date in this group here.

Ability to connect non SCIM-sync groups to Teams

Expected release date: By end of this week

Currently, you can only connect Teams to SCIM-synced Groups (hence the name SCIM-synced Teams). Starting tomorrow, you will be able to connect to local Atlassian Groups i.e. Groups that aren’t SCIM-synced.

Ability to connect your groups to an existing Team

Expected release date: January onwards

Today, you can only connect your groups to a new Team i.e. you are asked to create a new Team when using the feature. This feature will introduce the ability to connect your group to an existing Team, which will be connected to existing work already.

Public API for connecting a Team to a group

Expected release date: February onwards

There's no bulk method to connect a Team to a group. We'll be releasing a public API for this, which you can then use to handle bulk management. Comment if you need a true bulk API. 

Ability to rename your connected team

Expected release date: February onwards

Today, you create a new Team upon connecting a group.

We’ve heard your feedback and you will be able to rename your team to a more user-friendly name. This will only be available via the team profile at the beginning but if there is demand, we will also address the ability to rename the team upon creation within Atlassian Administration.

---

💎 Important considerations

You're all participants in this EAP as you submitted a form indicating that you possess at least one Premium license for any product.

• This will serve as an eligibility criterion moving forward, even upon the release of the new feature.
• Please note that if you decide to downgrade and no longer maintain at least one Premium license for any product, you will no longer have access to Managed Teams.
  • If this happens, the group and corresponding team will remain intact but the connection between the two will be removed.

If you are considering a downgrade in the future before Managed Teams is released to the public ~Jan/Feb, please inform me so that we can discuss appropriate steps to take. 

---

🙏 Thank you

Once again, thank you for your participation in this EAP. Your feedback has helped form this roadmap and the features. As always, please let me us know if you have any feedback by posting in this forum.

[Tomislav Tobijas _Koios_]

Great news! Especially the part about the ability to connect non SCIM-sync groups. Regarding the following:

It can only be created and deleted by organization admins in Atlassian Administration

On centralized user management, there is a user access admin role. Will users with this role also be able to connect and manage these Managed Teams/connect user directory groups and Teams?

[Jared Schmitt]

Comment if you need a true bulk API. 

YES. Ideally you provide an API for every action we as org admins can take.

you will be able to rename your team to a more user-friendly name

Will there be an API endpoint for that??

Context: Not being able to rename SCIM-groups made our company stop using SCIM for groups altogether, as we consider this a broken design. We really want to use Teams, especially with the upcoming Platform Experiences, but we need a proper API endpoint to manage Team names ourselves whenever they change (which they do pretty often unfortunately). Ideally, every name change on the connected group would result in a name change of the Team, without our need to act.

[Rune Rasmussen]

This sounds really good.

Public API for connecting a Team to a group

Expected release date: February onwards

There's no bulk method to connect a Team to a group. We'll be releasing a public API for this, which you can then use to handle bulk management. Comment if you need a true bulk API. 

A true bulk API would be hugely beneficial. I see the following use cases.

• The initial setup of this new feature
• Organizational restructures
• Company acquisition/integration

[Rune Rasmussen]

Another question.

Are there any plans to introduce control over who can can and cannot create Teams?

It's really nice that we're getting these expanded options, but if everyone and their grandma can still just go and create a new team it'll just be a matter of time (short time) before we end up with duplicate and abandoned teams.

It could be a toggle in the Admin portal, or a Product Role that could be assigned to users/groups.
A toggle would be nice, but the Product Role I think would be best.

[Rimantas Andrulevičius]

@April Chi will it be possible to send notifications to Team members? (via automation for example - similarly as it is possible with groups)

[April Chi]

Hey @Tomislav Tobijas _Koios_ 👋

Glad to hear! The ability to connect to non SCIM-sync groups aka local groups) has now been turned on for all our EAP customers. Have a go and let me know if you have any feedback! 

On centralized user management, there is a user access admin role. Will users with this role also be able to connect and manage these Managed Teams/connect user directory groups and Teams?

- Unfortunately, no. Only organization admins will be able to create/manage these teams.

- We plan to have some sort of a teams admin role eventually but I don't have a timeline for this yet (most likely not within the next financial year).

- If you'd like to help us in exploring this, would appreciate some use cases and an example of who in your organization would be creating/manage teams 🙏

[April Chi]

Hey @Jared Schmitt ,

Thank you for the feedback. 

YES. Ideally you provide an API for every action we as org admins can take.

Point taken, we will try our best to make an API available for the actions we're releasing. 

Will there be an API endpoint for that??

Context: Not being able to rename SCIM-groups made our company stop using SCIM for groups altogether, as we consider this a broken design. We really want to use Teams, especially with the upcoming Platform Experiences, but we need a proper API endpoint to manage Team names ourselves whenever they change (which they do pretty often unfortunately). Ideally, every name change on the connected group would result in a name change of the Team, without our need to act.

I'll pass that feedback onto the relevant team around renaming SCIM Groups. Initially, there won't be an API but we'll look at making one so you can manage it in a scalable manner as part of this EAP. Can you tell me what your ideal workflow would look like? i.e. would you use an API to connect Team to a Group then rename in bulk? Is there a naming convention you follow for Groups?

[April Chi]

Hey @Rimantas Andrulevičius ,

will it be possible to send notifications to Team members? (via automation for example - similarly as it is possible with groups)

Thanks for the question! What's your use case? Do you mean send notifications to team members that have been added to a Managed Team? Any extra context would be greatly appreciated :) 

[April Chi]

Hey @Rune ,

Another question.

Are there any plans to introduce control over who can can and cannot create Teams?

It's really nice that we're getting these expanded options, but if everyone and their grandma can still just go and create a new team it'll just be a matter of time (short time) before we end up with duplicate and abandoned teams.

It could be a toggle in the Admin portal, or a Product Role that could be assigned to users/groups.
A toggle would be nice, but the Product Role I think would be best.

Thank you for the question! Appreciate all the questions and feedback. Yes, this is on our radar. However, it's early days so I can't say for sure what this will look like but we are indeed looking at introducing more controls so Teams are easier to manage and better represented. 

re; your problem with this, is it just creating a team? What about the fact that anyone can delete or manage a team? 

[Jared Schmitt]

Thanks @april for getting back to my comment

Can you tell me what your ideal workflow would look like?

We store our organizational units (think: teams) + their members in our backend systems. Whenever there is a 

• name change of an organizational unit, we make 2 API calls: 1 for the corresponding group to rename it, 1 for the team to rename it
• membership change, we again make 2 API calls: 1 for the corresponding group to change the membership, 1 for the team 

As long as groups remain a concept in Atlassian, the ideal workflow would be that we simply change the group and the team just follows. But we're totally fine with 2 distinct change operations, we only need the API endpoint.

Is there a naming convention you follow for Groups?

Yes, there is. Basically it's <type of org unit>-<name of org unit>, like team-awesome-employees

[Rimantas Andrulevičius]

@April Chi The use cases to send notifications to Atlassian Team members:

1. Send notification to team members when team is set on a Jira issue (automation). We have clients who "pull" work assigned to teams. So team members want to get notified about issues assigned to their team.

2. Send notifications to team members that have been added to a Managed Team

On top of that having teams in Security levels and enabling the ability to use Team members in automations (like round robin assignment) would be awesome.

The end game is to have assignees based on Teams. And Teams based on asset categorisation on those issues.

[Rune Rasmussen]

Thank you for the question! Appreciate all the questions and feedback. Yes, this is on our radar. However, it's early days so I can't say for sure what this will look like but we are indeed looking at introducing more controls so Teams are easier to manage and better represented. 

That is good to hear.
I feel like a relatively high amount of features are being released without any real way for admins to control them, which is endlessly annoying.

re; your problem with this, is it just creating a team? What about the fact that anyone can delete or manage a team? 

The problem is in general. So it would also encompass deleting and managing teams.
Many users are very driven and self sufficient. They make their own decisions and act on them.
Many users also does not have the broader perspective in mind, and make changes (where they can) with their own needs in mind without considering much else.

So at least having the option to restrict who can create/delete/manage would be good.
Maybe we could take inspiration from the Jira Project setup and then have a "Team Lead" (or something) Role that can be given to a team member, or maybe "Team Admin" as a Role within the team.
The Team Lead would be able to administrate, but should probably only be a single person.
The Team Admin could be anyone in the Team, in the same way any user can have the Project Admin permission in a Jira Project.

Another thing, now that I'm thinking about it.
For User Picker fields we can define which group(s) you can select users from. Something in a similar vein would be good.
Maybe we could differentiate between "Team managed Teams" and "Company managed Teams".
Team managed could be Teams that are not linked to a group.
Company managed could be teams that are linked to a group.
If we could somehow define if teams linked to a group/not linked to a group can be selected in Team picker fields, that could also be very beneficial.
That would allow us to control when and where Issues can be connected to a team that matches our organizational structure (linked to a group) or teams that is for a value stream (not linked to a group).

[April Chi]

Thanks @april for getting back to my comment

Can you tell me what your ideal workflow would look like?

We store our organizational units (think: teams) + their members in our backend systems. Whenever there is a 

• name change of an organizational unit, we make 2 API calls: 1 for the corresponding group to rename it, 1 for the team to rename it

• membership change, we again make 2 API calls: 1 for the corresponding group to change the membership, 1 for the team 

As long as groups remain a concept in Atlassian, the ideal workflow would be that we simply change the group and the team just follows. But we're totally fine with 2 distinct change operations, we only need the API endpoint.

Is there a naming convention you follow for Groups?

Yes, there is. Basically it's <type of org unit>-<name of org unit>, like team-awesome-employees

--

Thanks @Jared Schmitt , I'll pass your use case back to my team and look at prioritising this API use case. 

Full transparency, we need to figure out capacity on where this ranks at the moment, but acknowledging that you're managing Groups and Teams at scale here making the API use case important and we will eventually need this.