Microsoft Teams Architecture Fundamentals for Creators
Microsoft 365 delivers a holistic digital workspace with many interconnected applications. So it’s crucial to consider how all the different tools interact and impact each other. Two essential pieces of the Microsoft 365-powered digital workspace are, of course, Microsoft Teams and SharePoint.
A lot goes on behind the scenes when you create a new workspace in Teams. While few of us need to know every detail, anyone involved in the management, creation, or administration of Microsoft Teams or SharePoint must understand some fundamentals. The tools do interconnect, and often different people or even departments own the two solutions.
To help us get a better picture of what happens during the creation process, we’re going to answer a common question many of our clients have asked, ‘what happens behind the scenes when I create a new workspace in Microsoft Teams?’
Microsoft Teams Essential Building Blocks
Let’s start with the basics. When I create (or provision) a team in Microsoft Teams, what do I get?
First and foremost, the foundation of your Teams team architecture is a Microsoft 365 group.
When you create a Microsoft 365 group in Exchange, Teams, or elsewhere, you get the following:
- Exchange Inbox & Calendar – Always
- Power Bi Workspace – Always
- Planner – Always
- SharePoint team site – Always
- OneNote notebook – Always
- Stream – Always
- Teams – sometimes
- Yammer – sometimes
- Project for the web – sometimes
- Roadmap – sometimes
Teams and Microsoft 365 group dynamics
From the Teams perspective, a team is looking to have a membership, a location to store team files, and a few items such as a method to organize team tasks and notes. Extending out a Microsoft 365 group, we can map team requirements to tools as every team must have the following building blocks in its infrastructure:
- Microsoft 356 group – as mentioned, the entire Teams team centers around it
- Along with a group, you automatically get a lot of other useful tools, including:
- Group email box and calendar in Outlook
- Planner – team task organization
- OneNote – team notes
- SharePoint Teams site
- SharePoint document library – all files of a Microsoft Teams team are stored in SharePoint. Further, each channel within a team gets its own folder in the team’s SharePoint document library.
Options for Microsoft Teams team creation
When you create a Teams team, you have a few options to get started. You can either
- Create a brand new team
- Copy an existing team
- Create a team from a template
After determining what sort of starting point you want for your team, the next question you should likely ask is, ‘do I want to create a new group or use an existing group?’
Creating a new Teams team from a new group
Creating a team from scratch creates a new Microsoft 365 group, and you get all the building blocks we have already highlighted. SharePoint and other assets will get provisioned automatically by Microsoft 365, proper folders are created that Teams needs to store its files, permissions are set, and you’re good to go.
Creating a Teams team from an existing group
Remember, when you create a Microsoft 365 group, you automatically get SharePoint behind it. So, if you tell Teams to use an existing group to create a new team, the team will hook itself up to that group, and in particular, SharePoint will be analyzed to ensure the required document library is available to hold the team files.
Email? We don’t need no stinking email!
Let’s get geeky for a second; Microsoft 365 group comes out of Exchange. This sounds technical, but here’s why it matters to you, in the context of Teams teams.
Microsoft 365 groups are owned/maintained by Exchange/Outlook—aka the people who work with email. Here’s how we see it: when Teams was first created, the Teams team needed a user membership and grouping mechanism, a security model, and a file system. Microsoft 365 groups (Office 365 groups at the time) made sense.
Yes, groups come from Exchange with an email address, and, well, Teams is not email. From the Teams perspective, they don’t really care about the email address. Therefore Teams looks to “hide” the email functionality of groups.
When you create a new team with a new Microsoft 365 group, that group is flagged in a specific way by Teams, which hides that group from Exchange. In general, exchange users, i.e., Outlook users and Exchange admins, won’t see the groups created by Teams. If this is a problem with an organization, you can remedy this by using PowerShell. When a team is created based on an existing group, the group continues to function as it did before in Exchange.
Teams architecture decisions can dictate gotcha considerations
Architecting and designing an application as complex as Teams, interconnected with Microsoft 365 in so many ways, has caused interesting tradeoffs that Microsoft 365 administrators should understand. As an example, let’s use private channels to help you visualize how feature architecture affects what’s going on behind the scenes.
When you create a team, the owner(s) of the team are also owners of the SharePoint site, i.e., site collection administrators. Further, SharePoint tenant administrators can also see all Teams team site collections. Essentially, team owners own the site collection.
Now, a private channel is designed to only be accessible by the members of the specific private channel. A team owner can see private channels exist, but they’re barred from accessing the private channel. This must also extend to files saved within a private channel.
Teams can do this, but SharePoint has no way to say, “even though you’re a SharePoint site owner/site collection admin, you cannot access a document library or folder.” SharePoint wasn’t designed that way.
So, when you create a private channel in Teams, it creates a new special SharePoint site collection. It’s special because Teams must ensure that no one has access to that site collection besides the people that are part of the private channel. Teams also wants to hide the private channel site collections from SharePoint global administrators.
This is one of many examples of how Teams has had to make architectural decisions on how to deliver the proper experience to end-users, while also working within rails provided by many of the underlying interconnected tools.
Beyond the basics
Now that you’ve gotten the basics, I’m sure you’re beginning to see how much is going on in the background. If you’re ready to dive deeper into your understanding of Microsoft 365 collaboration and communication architecture, check out these resources:
This series of illustrations from Microsoft provides a view into the logical architecture of productivity services for enterprise architects, leading with Teams.
These cloud architecture posters provide details about Microsoft cloud services, including Microsoft 365, Azure Active Directory (Azure AD), Microsoft Intune, Microsoft Dynamics 365, and hybrid on-premises and cloud solutions.
This series of topics from Microsoft illustrates several architecture approaches for mergers, acquisitions, divestitures, and other scenarios that might lead you to migrate to a new cloud tenant. These topics provide starting-point guidance for enterprise resource planning.
If your team is looking to truly take advantage of the Microsoft 365 suite as a holistic digital workspace, it’s imperative you understand the basic architecture. If you have any questions, please comment or reach out to us today!