What type of SharePoint site should I create?

Let’s talk about modern site creation in SharePoint and the key questions to consider before creating new SharePoint sites. Beyond the typical governance questions and requirements (eg. Site Name, Private or Public site, Template, Site Owners - 2 minimum, etc.) there are several high-level decisions made prior to creating a new site.

These decisions are:

  1. What type of site do you need: Communication or Team?

  2. Is this site required to be a Hub site?

  3. If a Team site, should it be Group Connected?

Communication Sites

Fundamentally, there are two major types of sites in SharePoint: Communication Sites and Team Sites. Choosing between these two sites is your first step in deciding what you need from a site. The other questions and decisions only come into play after this first important choice is made.

SharePoint Communication sites are used for showcasing content to a large audience or even the entire organization. For most of the employee audience, content is for viewing and not editing or collaborating. You will have a few content authors who create, edit, and update the content, but your typical user is visiting the site to consume information.

Example SharePoint Communication site with focus on images, news, and links

Team Sites

Unlike Communication sites, a Team site’s primary purpose is to create and collaborate on content. They likely have a smaller user base and most, if not all, users of the site create, edit and update content here. These sites are often created for a functional purpose or a functional team within an organization. They can be used to produce deliverables, track information, plan events, and create other content specific to the work of that group or function.

Standard SharePoint Team site experience

There are a few other types of sites you can create, such as:

  1. Content Centre sites are created to maintain and manage SharePoint Syntex document models.

  2. Project Web App (PWA) sites are an option if your organization uses Project Online to help manage and maintain projects.

These are used less often, depend on your organization and require fewer decisions to be made. These are straight-forward use cases, and it should be fairly obvious when to use them. If your organization doesn’t have SharePoint Syntex or Project Online, it wouldn’t be necessary to create these types of sites.

To sum up, here are our recommended principles behind using Communication vs. Team sites:

When to use Communication sites

When to use Team sites

“Showcase, share, story”

“Connect, Collaborate, Create”

Content primarily for viewing, not editing

Collaborate on deliverables, plan events, track status, exchange ideas

Large audience / whole org communication

Everyone or almost everyone is a content editor

Few content authors

Collectively creating assets

Examples: Intranet News, Employee how-to’s/shared Services sites

Examples: Project sites, Community of Practice sites


What’s the difference between site types and site templates?

Site Type: Communication Site and Team Site are the two foundational site types in SharePoint.

Site Template: Used to apply consistent configuration such as Libraries, Lists, Content Types and Views.


Hub Sites

A Hub site isn’t a type of site, it’s an attribute of a Communication site or Team site. Both types of sites can be registered as a Hub site.

A Hub site is used to connect sites with similar characteristics or a topic. These could be functional sites for a team, regional sites, divisional sites, or other characteristics that would require the association of sites to a specific Hub. An example might be Onboarding sites. You might have a break down like so:

Site Name

Site Type

Hub Status

Onboarding

Communication

Registered as a Hub

Pre-Onboarding

Communication

Associated to Onboarding Hub

Marketing Onboarding

Communication

Associated to Onboarding Hub

[Department] Onboarding

Communication

Associated to Onboarding Hub

This is not an organizational structure, but a function of the business. We are creating a central Hub and then associating additional sites to this Hub. We gain search scoping, branding, and navigation inheritance from a Hub association.

A site can only be associated to one Hub, but not all sites need to be associated to Hubs. If there is no reason to share navigation, branding, or search scoping then you don’t need to associate a site to a Hub. You can however, associate a Hub to another Hub and gain additional search scoping.

Note: it’s only recommended to go to three layers of Hub-to-Hub association, or the search scoping breaks down.

Group Connected Team Sites

So, you’ve determined you need a Team Site, but do you need a Group Connected Team Site?

When to create a Group-connected Team Site

By default, using the SharePoint end user interface to create a new site gives you a Group Connected site. This can be great if you need the additional resources that comes with Microsoft 365 Groups.

However, what if you already have a Group connected site and now, following best practices, you just want some additional sites (since we don’t use subsites anymore)?

When to create a Non-Group Connected Site

Let’s assume our Group Connected Team site is our main site for the Team and registered as a Hub site. We could create several Group Connected sites and associate them to this Hub, but that means we are maintaining multiple groups for the same user base. So perhaps a Non-Group connected site makes sense.

These need to be created through the Admin Center by a SharePoint Administrator or through an automated process (Site Templates, PnP Provisioning, Workflows) but they give us a Team Site without the extra overhead of a Microsoft 365 Group.

We suggest creating Group Connected Team Sites only if that group requires Microsoft Teams, Planner, a Shared Email and Calendar or any of the other resources a M365 group provides. If the group already has a Group Connected Team Site, creating additional resources for them may be unnecessary and confusing, so we can stick with a Team Site without a Group. We can always connect a group in the future if it becomes necessary, but we can not remove a group once connected.

In summary, here’s when we recommend using Group Connected vs. Non-Group Connected sites:

When to use Group Connected sites

When to use Non-Group Connected sites

Groups who collaborate together

Small groups with multiple sites (flat architecture)

Require additional shared resources (Planner, etc.)

Does not require shared resources, or additional shared resources

Functional unit or unique team

Not a unique unit/team, it’s just a unique function for a team

Child sites

Maybe you want a private site, but for a subset of a Team and you already have a Group Connected Team Site. In this case use a private channel in Microsoft Teams.

Example of a private channel in Teams

This allows a completely unique group of users (from the same team) to access this private channel.

However, keep in mind that the back-end of Teams is SharePoint (and OneDrive and Exchange), and when we do this we get a partial site that is connected to the parent site. This keeps our private group encapsulated in our main Group, which is great for those of us who have adopted Microsoft Teams as our primary place to work and collaborate.

Shared Channels

This is a new type of channel that is coming to Teams. It will provide the same functionality as a private channel and its child site, but allows cross-tenant collaboration. Meaning, we can collaborate with another organization in this channel without either organization leaving their own Teams environment. The site will live in the Tenant the channel is created in.

Summary

The most fundamental decision when planning SharePoint site creation is to decide what site type to use. First consider if a Communication or Team site is needed, then if it’s connected to a Hub, and if the site needs a Group. Finally, we recommend that groups use channels in Teams instead of creating separate sites where it makes sense.


Planning Teams and SharePoint sites is important for effective governance and compliance of information. If you need help or advice with Microsoft 365 governance, please reach out to chat.


Jeff Dunbar

Jeff is a technical expert in the design and configuration of SharePoint, Microsoft/Office 365 and Collabware. Jeff has created and maintained sites, site collections, and applications for SharePoint for small to large scale environments. He assists companies in managing their compliance using third-party add-ons and out-of-the-box records management. Jeff has planned and implemented information architecture, content management, content design, usability studies, and site re-designs.

Previous
Previous

Get the most out of Microsoft Lists

Next
Next

How to clean up a Microsoft Teams sprawl