Microsoft Teams and SharePoint Site Architecture: Explained
New to SharePoint sites? Read our latest article on 5 SharePoint Site Design Best Practices for Beginners!
This post is part of our Microsoft Teams Admin Guide series. Check out the other entries in the series below:
- The Latest Microsoft Teams Updates: App Store, Personal Views, & More!
- Guide: How to Get Started with Microsoft Teams Templates
- Why Microsoft Teams is Killing Skype for Business (and How to Prepare)
- Office 365 Groups vs. Microsoft Teams (Revisited)
- Top 10 Considerations for Microsoft Teams Governance
Many organizations today are facing the challenge of figuring out how Microsoft Teams plays into their corporate information architecture. It’s easy to see how this can be confusing; Teams isn’t exactly a site (even though we get a site with our Team if creating it from scratch). We get file-sharing capabilities similar to that of a SharePoint site (in fact, the corresponding SharePoint site is actually managing Teams files) so it really does feel like there’s redundancy between Microsoft Teams and SharePoint.
Since it’s been about two and a half years since its release, we can now go back and “teamify” existing sites so we no longer have to worry about ones that are truly redundant. That said, though, there’s still a lot to consider when talking about how all of these systems work together.
Let’s step back and examine our Microsoft Teams and SharePoint architecture from a best practices perspective.
Flat Architecture and Increased Administrative Visibility
Microsoft recommends that we restrict the use of subsites in our architecture (to read a great post on modern architecture, check out Stephanie Donahue’s write-up here). If you need a site, it’s better to think “site collection” rather than subsite. Below is a very simplified example of what we’re talking about. Every site is its own “top-level site” or site collection.
I’ll admit, when I originally read that recommendation, my first thought was, “That’s a lot of site collections to have in the Admin Portal.”
However, that’s not necessarily a bad thing. It’s actually useful because it now allows us to see what we’re working with within the environment. Also, the tangled knots of granular permissions that tend to mess up our deeper site collections are now a thing of the past (hallelujah!).
When a new site is needed with a specific set of permissions rather than creating a subsite and breaking the inheritance of permissions, a new site (collection) is created and we have fresh, new permissions to work with.
Choosing a Site Template
SharePoint offers us two site templates: Communication and Team. They are each built with specific use cases in mind.
The Communication site template is designed to communicate information to a particular audience. For this reason, Communication sites are the preferred template for our corporate home page and our “company public” department home pages that has information everyone in the company needs access to (such as HR). This information would include benefits information, enrollment forms, job descriptions, and wellness events.
Team sites are (and always have been) the site template of choice for our collaboration sites. These sites hold “department-private” data that no one in the company should have access to except for the team that owns and manages it. For HR, this would be information like submitted insurance forms, employee reviews, pay scale data, and the department schedule.
Looking for more info about the architecture behind Microsoft Teams? Check out this post: Click To TweetLet’s Not Forget the Hubs
So, how do we take all these separate site collections and create consistent navigation for the organization? We hubify! Hub sites aren’t a type of site by default. Both a Team and Communication site can be turned into a hub site so, in practice, it’s more so a feature that we can enable on a site.
Hub sites are used to bring context and coherent navigation to our flat architecture. We can hubify our corporate home and join department sites to it, so we have consistent navigation throughout the open areas of the intranet. Alternately, we can have sets of smaller hubs in the architecture for things like “Projects” or “Shared Services.” The link to those hub sites can be placed in the Corporate Home hub so it’s part of our persistent intranet navigation.
Hub sites also bring a modular element to our architecture. When the inevitable reorganization of the company happens, we can just unregister our site from one hub and attach it to another as needed.
The more private team sites won’t need to be linked to on the corporate home page since we don’t want everyone in the organization trying to access Finance or HR’s team sites. Thus, you don’t need to stress about looping that into the more “global” intranet navigation. Work with your individual departments to build out their team site navigation so they can get to all the “behind the scenes” stuff they need.
Teams for Collaboration
Now that we’ve touched on communication sites, team sites, and hubs, let’s get to the good stuff: Teams!
Microsoft Teams has positioned itself very centrally in the collaboration space. Our internal communication and conversations can now move out of disjointed Skype for Business messages and random emails into a persistent chat. The full history is available alongside a handy search function.
Gone are the days of having to remember every team member to add to an email thread; post that message in the appropriate Team channel. Done and done. You’ll never again have to go forward a ton of emails to the new hire; just add them to the Teams where they’ll be working. As users become immersed in the Teams experience, we start to see internal communication shifting to these Teams and channels and reducing internal email traffic.
Tabs for productivity
Tabs transform our channels into streamlined productivity hubs. The big advantage to tabs is being able to bring the resource we need to us in Teams rather than completely context switching and going out to another browser, application, or screen. Add tabs to your Planner plans, Stream channels, or whatever resource your team needs. For a great resource on tabs in Teams check out Microsoft’s article on utilizing built-in and custom tabs.
But That Site…
As mentioned at the start of this post, the whole situation with new Teams creating a whole other team site can feel confusing and redundant—but it needn’t be. Remember, if we already have a modern team site full of important content, we can simply attach our new Team to that; we just have to groupify it first.
Either way we get it, let’s take that Teams’ team site and build it out as out as our department (or project, or campaign) collaboration site. This would include calendars, lists, libraries, and links to various resources such as Stream for videos, Planner, and external resources. You can also add tabs in Teams to connect to important content in the team site (even documents!).
The only difference with a Microsoft Teams-connected team site is that there are going to be folders in the Documents library for the organization of Teams’ files (one per channel). You can create views in this library so you can sort through content without the annoyance of folders, but do not delete those folders. Use that library as your Microsoft Teams “file share” and build out other libraries as needed for content organization.
The Big Picture
Now that we’ve looked at the different pieces of our intranet architecture, let’s get a view of the big picture. It includes the following components:
- Communication sites for our “Company Public” sites that hold information that everyone in the organization should have access to
- Team sites for “depart private” content that only specific departments, business units, and project groups should have access to
- Hubified sites, as needed, to connect sites that have similar scope spread across multiple sites
- Microsoft Teams for enhanced collaboration within teams, departments, and groups
Putting all of these pieces together will ultimately look something like this:
In a Nutshell
With Microsoft encouraging us to flatten our architecture and create new sites for content rather than subsites, we’re in a position to build more modularly than in years past. This enables us to create an intranet that is logically structured yet agile enough to work the way the business does.
One site per purpose = building blocks of content that can be stacked and restacked as needed without the need for migration tools or massive rebuilds of our environment. Permissions stay clean and the admin portal presents a true picture of the content we have in the organization rather than it being hidden in deep subsite structures.
We’re positioned for success by leveraging Microsoft Teams with our team sites. Not only does it provide a centralized, collaborative workspace, but Microsoft Teams provides access to important apps, files, and sites from a single interface. This becomes an enhancement that streamlines into our architecture rather than a bolt-on app that may or may not be in tune with line of business needs.
