By design, Microsoft Teams empowers end users to structure their workspace using different channels to logically separate content and collaboration areas in a way that works for them.
There is no defined “right” or “wrong” way to structure Teams and channels but there are some limits and best practices that can be followed to ensure the structures created are easy to use and navigate.
In this article, I’ll explore the decision process Team owners can use to assess if a new channel is needed, what type should be used and how to manage large numbers of channels in a team.
What Types of Channels can I create?
Before creating a Team or channel, it’s important to understand the different available channel types. For more detailed information please refer to this article Understanding the Three Types of Channels in Microsoft Teams which effectively breaks down the differences between regular channels, private channels, and the upcoming shared channels which will be available later this year.
Team and Channel Limits
The limits associated with Teams and channels evolve as the platform grows so it’s worth keeping track of current limits from the Microsoft Documentation. Some of the more important limits to consider when determining if a new channel should be created are shown in Table 1:
* This includes deleted channels; deleted channels are available for 30 days after deletion and cannot be removed prior to this. For example, if you have 30 Private channels and delete one, you cannot create another until the 30-day retention period expires.
** After the first 20 users in a Group Chat, rich features such as status messages, typing indicator, group calling, and read receipts are disabled.
What about the General Channel?
By default, every new Team gets a General channel. This is the first channel in every Team and it’s easy to end up using this as a dumping ground for all content. As it’s not possible to rename the General channel, content within the channel does not have the nice classification of being associated with a specific Channel name. In my experience, the General channel is best used to serve as an area where discussions and content relating to the Team itself can be held.
For example, requesting that a new member is added to the Team is not something that requires a specific channel and usually does not relate to the workstreams that the other Channels refer to, so the General channel is perfect for this. Another example is for storing onboarding documentation for how the Team is to be used, this can define the processes used within the Team if required.
Considering Group Chats
Group chats are distinct from Teams and channels and can be used for informal, short-term collaboration. There are some points to consider around using group chats for collaboration:
- They don’t have dedicated storage; files are held within the senders OneDrive and subject to OneDrive retention policies, not Teams policies
- Membership is managed separately and informally, there is no ‘owner’ for a group chat and anyone can add or remove members by default
- Removing members from group chats can be controlled via Teams Messaging Policies
- They don’t support rich features such as Tabs, Channels, Apps, etc.
Group chats can be great for discussions between a subset of a Teams members and for when content is not ready to be shared with the entire Team but they don’t replace Teams and channels.
When should I use Private Channels?
Private channels were a much-requested feature from the launch of Teams. Essentially, private channels are an area of a Team that does not inherit membership from the parent Team and can be used as a restricted area for conversations and collaboration that not everyone in the Team should see.
This can be extremely useful when you don’t want to break the overall information architecture of the Team but have a requirement to lock content behind a specific permission set (or Roster). Given the much smaller limit on the number of private channels that can be created, along with the fact that the underlying SharePoint storage is independent of the Team site, it’s worth considering if there is a real requirement to block access to content within the channel or if it’s just something that other Team members won’t be interested in and can hide within their client.
Some examples of private channel use cases:
- Managing the financial aspects of a project within a project Team
- Providing an “internal only” area in a Team with external guests
- A management area within a large or company-wide Team
Read more: How to Report Teams Channel Storage with Microsoft Graph API and PowerShell (practical365.com)
Channel Settings
When considering the channel architecture within a Team, a nice feature is having specific channel settings for each channel that is created. The individual channel settings can control moderation and message permissions (Figure 1).
For example, if a new channel is created to publish updates for a specific project, regular channel members can be prevented from starting or replying to posts within that channel. This can all be done on a per-channel basis to allow for flexibility in the structure of the Team.
Guest Users
As with regular users, Guest users can be brought into Teams to collaborate as part of the group. Permissions for Guest users can be defined within the Team settings as shown in Figure 2, by default they will not be allowed to create, manage, or delete channels.
To participate within a Team, an external user must be provisioned as a Guest user within the tenant, however, when using a group chat, guest users can be brought in once they can federate with your organization. By default, federation is open but some organizations may choose to implement an allowed/blocked domain list to manage federation.
Note: When an external user is added to a group chat, a new chat will be created, and the chat and file share history from the original group chat will not be available to them.
Teams Templates are very useful
When creating Teams for general use, the Teams templates feature is a terrific way to provision a Team with all the most common requirements in place. Templates can be used to predefine a Teams structure (Channels, Tabs and Apps) that is then used to create the Team. This takes a lot of the guesswork out of the process for regular users.
There is a wide range of built-in templates readily available and custom templates can be created from scratch, or by copying the structure of an existing Team. This means that the most common use cases for your organization can be predefined and offered as a “catalog.” For example, an organization that goes through multiple acquisition projects and uses Teams to manage the process can predefine a template to ensure that the structure provided is identical for each project, even when there are different team members involved. When a Team is deployed via a template, it can then be customized and updated but the initial object will always be the same. Deploying templates is quite easy and end-users can preview what they are provisioning before committing to creating the Team:
Do you even need a Team?
As Teams has grown and been adopted at an extraordinary rate across organizations, one question that’s often forgotten when creating a new Team or Channel is – do we need a Team for this? For example, when creating an area to store documentation a Team or channel may not be required at all. Teams brings a lot to the table with the collaboration aspects of conversations, tabs, and apps, but the question should be asked if all that functionality is needed or if a basic SharePoint team site will meet the requirements.
Confusing naming overlap aside, a Team Site/Document Library will give users a location to store, share and collaborate on documents without the extra noise a Team brings with it. Even better, they can be added as a tab in an existing Team to bring it all together as shown in Figure 4. This can be done easily with the Document Library Teams app. One drawback to this method is that permissions on the site/library are managed separately from the Team itself.
Organizing Teams and Channels within the Teams Client
As Teams grow with multiple channels, not every channel is of interest to every member of the Team. As a Team owner, channels can be set to show in everyone’s channel list. This allows Team owners to define up to 10 channels that are important to the Team while allowing users to hide or show other channels as required using the Team channel settings shown in Figure 5:
Users will always see a channel that has a pending important notification for them, regardless of if it is hidden or not.
Another nice feature is the ability to ‘Pin’ channels in the Teams client, giving quick access to the channels that are most important to you by making them always available at the top of the Team/channel list.
Summary
With all of this in mind, if we back to the original question – ‘how many channels should a Team have?’ There isn’t a definitive answer to this, unfortunately, but you can use the below guidance to help make the right decision when creating a channel.
Keeping channels to a minimum is a good practice to help Team members locate content quickly and efficiently, keeping in mind the limit of ten channels that Team owners can set as always shown for members. However, there is nothing wrong with having large numbers of channels once they are all distinct, significant areas of collaboration within the Team.
Consider the alternatives to Teams and channels when deciding to make sure that your requirements are met at the right level and not driven by the solution. You probably don’t need a Team or channel to have an ad-hoc informal chat with your colleagues, or to store some old documents for reference, but for that rich collaboration complete with apps and tabs, Teams is brilliant.
It’s also important to be aware of the limitations on channels, particularly when dealing with multiple private channels so you don’t end up waiting 30 days for the retention to expire on a deleted channel before you can create a new one.
In summary, sometimes less is more when planning Teams channels. However, Teams is a very flexible tool, and the logical structure of the Team should meet your organization’s needs without overcomplicating it.
