Love it or loath it, over the last few years Microsoft Teams has emerged as the dominant collaboration tool for companies, large and small. But, let’s face it, how much has the typical organisation invested into getting the most out of Teams? The same can be said for most of Microsoft 365 – we buy the licences and expect people to just get on and use it.

I could, and probably should, write a post about technology adoption, but this one is about Teams. Specifically about when to create a chat and when to use a channel. And what sorts of channels to use when. And if you want a post about technology adoption, here’s one I wrote several years ago…

You see, a few weeks ago, I was fortunate enough to attend the Commsverse conference. And one of the talks I found insightful was Robert Mulsow (in/robert-mulsow)’s “How to select the right communication in Teams: Feedback from the field”.

What’s the problem?

Teams has two forms of text-based chat:

1. Chats, created from a conversation. Informal. Ad-hoc. No real management.
2. Channels, created as a shared space within a Team. Designed to scale, supported by SharePoint.

My (organisational) team has both! And no-one knows where to post:

• We have a “chat”, but that’s been problematic since one of the team (who probably created the chat) left the organisation. And there’s not much that an admin can do to support a chat – it’s all down to users.
• We also have a Team, with some channels. But some people in the team prefer to use the chat (something to do with notifications). Oh yes, and we currently work across four Microsoft 365 tenants. That will change, but for now it’s not easy (that’s mergers and acquisitions for you…)

Which to use when – chat or channel?

It’s actually quite simple. Use chats for 1:1 or 1:few conversations. And then leave them behind, until you chat with that person or those people again. Chats are not intended to scale. They are for ad-hoc comms with small groups of people. They are absolutely not intended for groups of many people.

When you want to create a collaboration space, create a team. That team will have a “General” channel, and you can create more to suit the collaboration requirements of the team. 

Simple. All I need to do now is convince my colleagues to stop using the team chat. Hmm. Maybe not so simple.

But there are many different types of channel!

Channels inside teams can be standard, private or shared.

To understand these, it helps to understand the relationship(s) between Entra ID (ex-Azure Active Directory) and Teams. And that comes back to the concept of a tenant. I wrote about tenants a few years ago.

Think of your tenant as an office block. When business partners visit from another office block, they come through the entrance area. If they have the wrong badge, they won’t get in. They are signed in as guest and escorted to a meeting space. That’s how it works in Teams when you are invited to a meeting.

Now, let’s go a bit further with this analogy. Regular guests may get their own badge and they can go directly to meeting without being escorted. They are not just authenticated but are authorised for access. Channels are the Teams version of rooms that guests can go in/out of.

Once upon a time, to switch tenants, we had to exit Teams and go back in with some different credentials. In our office block analogy that’s leaving the building and going into another. But now, it’s more like a bridge between (office blocks). You can access another tenant with your own “badge” – you don’t need guest access.

This is where Shared Channels work. It requires a trust to be established in Microsoft Entra ID and in technical terms it uses external identities and cross tenant access settings. This is more difficult to control as there are no specific badges to revoke – it relies on a trusted partner organisation to provide access. The key word here is “trust”.

In our analogy, shared channels really just show the corridor and the room, everything else in the office block is hidden from view (behind locked doors).

Confused?

All of this flexibility is potentially confusing so let’s bring it back a level – think about what you want to share. And it’s not as clear with external access and shared channels as it was when you had to exit/enter as a guest.

It gets even more complicated with sensitivity labels – they are inherited. You can’t drop down to a lower level of security later. Let’s just leave that to one side for a moment.

Which to use when?

Which to used depends whether you are collaborating or communicating.  

• How many people are involved? You can add people to a chat but they don’t inherit the permissions on files. When you remove members they can access existing information but can’t add more.
• Chats can get out of hand quickly so in most cases you’ll want to consider a team.
• If you don’t already have a team, think about about future requirements and scope. You might just create a channel in an existing team!
• If there is already a team in place, check if there is a channel for the topic and post there or create a channel as applicable. And what kind of channel will be driven by its intended use. And you must have policies to allow.

Here’s a flow chart to help the decision!

As you can see, it’s too complicated really. People just want to send a message. But, if the necessary Teams and channels are in place, with guidance, then it should be straightforward.

I’ve added a little more of Robert’s guidance to consider in the table below:

And, in addition to all of that, issue some clear collaboration guidelines for people to follow.

Conclusion

Chat or channel is simple – if you want to collaborate, or to communicate with more than a few users, choose a channel. The type of channel is less straightforward – but in most cases you’ll want a standard channel in your Team. Only when you start sharing information across organisational boundaries (between tenants) will you need to think about guest access, shared channels and private channels.

Featured image: Microsoft Image Gallery