Getting Ready for Private Channels in Microsoft Teams: Part 2

In part one of this series, we dove into why the release of private channels is so key to having Microsoft Teams support the way real-world teams actually collaborate. Since that first post, we’ve been chomping at the bit to get into the details of how private channels actually work. This week at Ignite, Microsoft formally launched this much-anticipated new capability to much fanfare. Now that the lid has come off the can, we’re able to spill all of the details you’re probably wondering about—so let’s get started!

At the most basic level, private channels work the way you would expect. First off, it’s a channel that is functionally like the standard channels you’re used to. If you have access to the private channel additional tabs can be added to expose 1^st party Microsoft applications (such as SharePoint, Planner, OneNote, PowerPoint etc.) as well as 3^rd party applications from many different providers. One slight difference for private channels at launch time is that not all apps and tabs will be supported. For example, bots and apps that leverage message extensions will not be supported when private channels are initially launched.

Another level of membership?

So, as you probably have guessed, adding the ability to define access to a channel to only a subset of the overall team mandates that we now have to maintain another level of membership tracking. As we covered in part one, the membership of the team is simply the membership of the underlying Office 365 Group; if we’re going to have a more restrictive list of members in a private channel, that “list” of channel members needs to live somewhere—and it actually lives in Teams.

What we have here is essentially a security boundary below the Team level. Therefore, Microsoft Teams now has both “members” at the team level and, for private channels, “members” at the channel level. This is the reason why, once private channels have rolled out to your tenant and the ability to create private channels is enabled for you (more on that later), you will need to define the channel “privacy” when you create a new channel. Microsoft Teams needs to know if it’s a “standard channel” (i.e. visible to all team members) or a “private channel” where Teams needs to maintain a list of allowed users.

If you opt for a private channel, you will now have “channel members” and “channel owners” scoped to that particular channel.

When viewing the membership in the screenshot above, we can see the scope of what we’re managing. Note the visibility badge on the top right of the screen. When managing a private channel, this badge is intended to remind us that the settings we make here only affect this channel.

“Channel Owners?” I thought the Team already had owners?

Yup, you heard right–the private channel also has an explicit list of owners and it can be a different set of owners than you have for the Team as a whole. What can a channel owner do? You guessed it—they can manage the members and owners of that private channel, as well as modify any relevant settings for that private channel. These private channel settings are many of the same channel-related settings that are available for Team owners to configure for all standard channels, like setting member permissions for adding tabs, editing/deleting messages, @-mentioning, and so on.

It may come as a surprise that you can be a private channel owner even if you’re not an owner of the overall Team. As a matter of fact, you may have no Team owners in your list of private channel owners. While this might seem odd and even counter-intuitive at first, it actually makes perfect sense when you consider the business scenarios that make private channels so usable.

In the first post, we introduced two simple but common scenarios where you will most likely want to employ private channels. Let’s take the “management channel” example: I may be the top-level manager for a department, and I may want to decide who should be part of my secured management conversations, but that doesn’t mean I want the responsibility or burden of managing the team as a whole. Likewise, just because I’m tasked with managing the general Team, that doesn’t mean I should be able to access all of the more sensitive collaboration happening in those private channels unless I’ve been deliberately added to them.

It’s here that we reach a key concept in how Microsoft approached private channel collaboration: EVERY effort has been made to ensure that the sensitive conversations and files that live in these channels don’t leak beyond the security boundary they’ve created for that channel.

Keeping private channels PRIVATE: Who knows they exist and what can they do with them?

In keeping with the “private” nature of private channels, only those that need to know about the channel can actually see it. Owners and members will see the private channel in their channel list for the Team just as they see standard channels (though the private channels will be differentiated by the presence of a lock icon noting that the channel is indeed a private one).

If you aren’t a member/owner of a private channel, the channel will simply be missing from your channel list. This behavior is the same both in the left-side navigation and in the “channels” section of the “Manage Team” interface. In that view, standard channels now get a globe icon and we again see the lock icon for private channels that I have access to:

If you are a team owner BUT NOT a member or owner of the private channel, you can see that the channel exists in “Manage Team” but you cannot access it or manage the membership/ownership of it. Microsoft provides a handy table showing who can see what as far as PCs are concerned:

Further, Microsoft also provides a comprehensive list of “who can do what” with respect to interacting with and managing private channels:

File Storage for Private Channels: The SharePoint Thing…

Let’s think back to the file storage model for standard channels. Files for each channel are stored in a subfolder of the Team’s SharePoint site that is bound to the channel. This is a convenient approach that segments the files according to the collaboration topic, but it doesn’t quite cut it for private channels. Why? There is a simple, and very “SharePoint-y” reason… Site collection admins cannot be restricted from ANY site, library, folder, or document in their site collection—that’s part of the protection in SharePoint that ensures lower-level site admins cannot block higher-level admins. Unfortunately, in the case of private channels, that’s exactly what we want to happen, so another approach is needed.

Let’s take an example:

For my “Secret Project” scenario, the Team owners are not part of this project, nor should they be able to see what’s happening in this channel. We can see that we’re covered on that as far as conversations go from the info we discussed already. But because Team owners are always added as site collection admins to the SharePoint site associated with the Team, I cannot have my secret project files stored anywhere within the Team’s site collection if we are truly to keep those files from leaking to people who should not see them (in this case, my team owners).

If those files cannot exist in the Team’s site collection for this reason, there’s only one alternative: they need to be stored in their own site collection. Luckily, that’s exactly what Microsoft Teams does–when a new private channel is created, Microsoft Teams will automatically provision a new SharePoint site collection to support it, and the private channel owners will be the site collection admins and be in the “owners” group for the SharePoint site. The members of that private channel will get added to the SharePoint “members” group, and the Team members that aren’t part of the private channel will have no access to the site collection at all.

Yup, you read that right–and there will be much shouting about this one. SharePoint die-hards (and it takes on to know one ?) will no doubt start screaming about “site sprawl” and start sweating thinking about how many additional site collections will now start sprouting in their tenant. After all, if we have an average of two private channels for each Team we have, we’re now looking at THREE SharePoint site collections to support that Team, not one. But sprawl isn’t really about a number of site collections; it’s a condition we’ve tried to avoid in SharePoint where we lose track of what we have and why we have it. On that front, Microsoft Teams has gone to great lengths to make sure that these newly-spawned site collections are tightly aligned with the private channels they belong to. Some examples include:

• When a private channel is created, the automatically provisioned site collection is named in such a way that we know what Team and channel it belongs to. The naming convention teamName-privatechannelName is used:
• The site collection backing the private channel is using a “lightweight” site collection template unique to sites that are backing private channels: teamchannel#0. This unique template ID comes in handy when you want to use PowerShell for other programmatic methods to find all your private channel site collections. Since this template is primarily used for storage, the home page of the site is the Documents library and the site contents are fairly sparse (example: no “Pages” library),
• There’s a persistent banner when accessing the channel folder in the Documents library that shows this site is associated with a specific channel and offers easy navigation to get back to that channel:
• Microsoft Teams will keep the SharePoint “owners” and “members” groups in sync with the owners and members of the private channel. Unlike a site collection backing a Team as a whole (which provides access to the site for Team members via the Office 365 Group object), private channel site collections need to provide access for members and owners using their explicit user accounts. Because membership of the private channel is “mastered” in Microsoft Teams, Teams will add the members to the SharePoint members group and owners to the SharePoint owners group explicitly. As private channel members and owners change in Teams, those changes are replicated into the SharePoint members and owners groups immediately.
• Further, Microsoft Teams will check periodically (seems to be about every four hours based on my testing) and revert any changes made to the SharePoint members and owners groups that were not initiated by Teams. So, in theory, you should not have to worry about maintaining the permissions of these private channel site collections. In the real world, however, be aware that SharePoint is still SharePoint and, outside of the owners and members groups which are being handled by Microsoft Teams, you may still have to be mindful of explicit SharePoint permissions and anonymous links (depending on your SharePoint sharing settings) that are granted to the site collection or its content over time.
• Private channel site collections live and die with their associated channel, so you should not have to worry about the “lifecycle” of these sites separate from the channel. When a private channel is deleted in Microsoft Teams, all of its assets–including the SharePoint site collection–are deleted as well. Teams will allow 30 days for the recovery of that private channel, and if recovered through Teams, the site collection will be restored as well.
• I’ve spoken to a few customers who have been concerned about hitting the stated limit of 500,000 site collections for their Office 365 tenant once these new private channel sites start spinning up, but Microsoft is already ahead of that one; the new upper limit will be 2 MILLION site collections per tenant (!!!).

What About the USER’s Experience with This SharePoint Approach?

The bullets above should mitigate much of the administrative and management concern of the private channel file architecture decision Microsoft has made. But what about the end users? Will there be confusion that some of the Microsoft Teams files are in one site collection while the private channel files are spread across additional site collections? How will they find and track all files associated with the team as a whole?

In some ways, the fact that we are even having that discussion is a sign that the user experience for interacting with Team files to this point has not quite been up to the billing of Microsoft Teams as the “Hub” for teamwork. Up until recently, if you wanted to perform basic file management operations like moving files, creating and applying metadata, kicking off flows, or syncing a library, you had to resort to the unfortunately necessary “Open in SharePoint” option from the Teams “Files” tab for your channels. To do this right–especially now that the SharePoint story for Teams is more complex—we need a first-class files experience right inside Microsoft Teams that doesn’t require the user to even be aware of the SharePoint complexity on the back end.

Fortunately, another announcement here at Ignite 2019 is the long-awaited release of that first class experience we’ve been waiting for. At long last, you’ll see a near full-fidelity modern SharePoint file library experience right within the Files tab for your Microsoft Teams channels. Teams users should now be able to simply move from channel to channel in the Teams interface without worrying if the files they need are in the Teams site or a separate private channel site.

Rolling All of This out Smartly

Armed with the info above (in addition to all of the business justification we covered in part one of this post, you should now have a good idea of not only why private channels are so important, but also how they work at a granular level. All that’s left is to decide how you will make this capability available in your tenant.

In part one we told you about how to set up a teams policy to determine who in your organization has the right to create private channels. This is the first step to take if you want to roll out private channels slowly in a limited pilot. Further, Team owners have a new setting available to them that determines if private channels can be created by Team members.

This means there are actually two gates that must be passed before a Team member (non-owner) can create a new private channel:

• The Team must be set to allow private channel creation by members, AND
• The user attempting to create the private channel must have a Microsoft Teams policy applied to them that allows them to create private channels in general

This concept of both a Teams-wide private channel creation setting as well as a Team per Team setting means you should be able to find the right level of control over who can create Private channels and where.

Summary and What’s in Store for Part 3 of This Series

As I hope is clear from this blog series, we here at AvePoint are thrilled that private channels and the capabilities they offer will now be rolling out to customers at large. For those of you in the government clouds like Office 365 GCC, GCC High and DOD, know that Microsoft is committed to getting this functionality out to your tenants as soon as possible. We are also working hard on new capabilities in our AvePoint Online Services platform to further enhance and operationalize the use of private channels in your Office 365 deployment, and we’ll see these features roll out throughout the next few releases of Cloud Governance and Cloud Backup.

We’re also working hard on the third and final part of this blog series which will cover all of the compliance, retention and eDiscovery implications of the private channel architecture detailed above. We’ll review how retention and automated deletion of files and conversations work for private channels and how you can ensure your compliance teams feel comfortable allowing the broad rollout of private channels within your organization.

Other Great Private Channel Blogs We’re Reading:

• Everything You Need to Know About Private Channels by Matt Wade
• Managing Teams Private Channels by Tony Redmond

Want the latest insights into private channels? Be sure to subscribe to our blog!