A Team is at the heart of what we can use Microsoft Teams for to aid us in group-based collaboration, sharing, and more. The number of Teams can get out of hand quickly in a company so sometimes, we want a way to limit how and when they are created to make sure we’re keeping on course.
By controlling permissions in Azure AD, we have the ability to restrict Team creation in Microsoft Teams. We don’t want to stop people collaborating: we just want to make sure they are doing it in the way that meets the meets of the business and any security and governance concerns we might have along the way.
In this article, we’ll talk about not just how to actually restrict the creation of Teams but the underlying thought process like why we would want to do it and what some of the different configurations might look like.
What is a Team?
I guess we should quickly explain what a Team actually is in Microsoft Teams as to some people who are new to the product amid increased remote working and change, it may be a new concept.
A Team is a space that people can come together to collaborate and to work on a shared topic. How you create and use teams may vary from organisation to organisation and there isn’t a prescriptive statement on when to create one.
Company A may create a Team for each of its departments to use so that they can work together within their departments. Company B might create a team for each customer that they work with so that people can use the Team as they start working on a project with that customer. Company C might create a Team for each project that they undertake and Company D could do something that’s a combination or A, B, and C.
When we create a Team through Microsoft Teams we are actually creating an Office 365 Group behind the scenes. A Team in Microsoft Teams is an Office 365 Group which has been Teams enabled. We can also Teams enable existing Office 365 Groups.
An Office 365 Group is a special kind of group that exists in Azure AD and the Microsoft 365 suite. Once created, an Office 365 Group spawns other sub-elements such as a SharePoint Team Site, an Exchange Online Mailbox, a OneNote Notebook, a Planner Board, and a Power BI Workspace. There is a great graphic illustrating this at https://techcommunity.microsoft.com/t5/office-365/office-365-groups-explained-new-blog-series/m-p/40288.
You can actually create an Office 365 Group from many places within Microsoft 365 such as from Outlook, SharePoint, Planner, Microsoft Stream, and more. The fact that they can be created in so many ways is one of the reasons that we may opt to restrict team creation.
So why might we want to restrict Team creation?
To answer the question you need to remember that by default in Microsoft 365, any user in the Tenant has the ability to create a new Team or a new Office 365 Group.
From a collaboration standpoint, this is very attractive and people can self-service get down to business working with their colleagues, however, in practical terms, it doesn’t take long for Teams to be pouring out of your organisation all over the place. Team and Group creation warrant governance: managing creation, ownership, delegation, security and protection, and lifecycle.
How do we restrict who creates Teams?
The restriction process itself is actually far less complicated than deciding who to restrict it to. There are two simple steps, the second of which requires you to have the Azure AD PowerShell module available.
The complete steps can be found at https://docs.microsoft.com/en-us/microsoft-365/admin/create-groups/manage-creation-of-groups?view=o365-worldwide.
Step one is to create a group. We use this group to assign permission for group creation so that we can easily add and remove members in the future without having to break out PowerShell to Azure AD again.
With the group created, we use Azure AD PowerShell to set the property using the Set-AzureADDirectorySetting command to match the ID of our created group.
Who should we restrict Team creation too?
There isn’t a 100% correct answer to this.
Some organisations which are extremely sensitive or risk-averse may want to fully lock it down such that only IT or very specific individuals can create a Team. This gives you tight control and governance, however, could hurt user experience and adoption.
If your organisation wants to embrace user-driven Teams creation but wants to limit it to people that have undergone super user training then having Teams Champions within each department or across the business that can act as conduits for creating Teams for other users may work. This approach addresses some of the concerns, however, you need to find a way to make the champions accessible to other users and to publicise their status as a champion so that users know where to go when they want a Team created.
A Service Desk driven approach to Team creation
One option we do see as viable in organisations which have the framework to support it is a Service Desk, self-service driven process for Teams creation. With this option, any user has the ability to create a Team, however, only the service account of the Service Desk toolset has the permission to create them. In this scenario, for a user to create a new Team they would request it via a Service Request management system such as ServiceNow. The workflow would be automated so that no manual Service Desk intervention is required, however, the fact that users are required to go via a process means that there is a record of all creation events in the toolset but also, you can programmatically create them allowing you to add some organisational magic to the process such as setting up governance, sending out emails to requestor instructing them on how to get started with their Team and more.
Managing with policy
The final option which we are going to touch on loosely here is restricting Team creation [or moreover manage Team creation] by policy. With this option, we are still allowing all users to create a new Team on their own, however, we implement all of the controls and features within Azure AD to police their naming, use, and expiration.
This is a broader governance topic and something we will be covering in more articles over the coming days and weeks.
Restricting Team creation in summary
In brief summary then, there isn’t a bulletproof answer to this problem. Each organisation will need to determine their own path for success.
At Arcible, we’ve worked with customers of all shapes and sizes and have seen various different strategies work. Get in touch with us if you would like to learn more or need support in determining your Microsoft Teams adoption and Team creation strategy.