Attempting to explain Teams shared channels to end users

Shared channels in Microsoft Teams are not exactly new, but at the same time relatively recent. Consistently amongst organisations and IT Pros the resounding commentary I’ve heard is that they are too confusing and have been disabled.

The problem is that shared channels are a mix of experiences borrowed from private channels and guest access, with extra layers of control wrapped around them.

My biggest frustration with the approach of disabling shared channels, is that I wished people did the same for private channels and guest access in the first place. Not because I think features should be disabled, but more so because I believe any feature before being made available to end-users should come with (in no particular order of importance):

• Governance to ensure the organisation remains compliant.
• Support to ensure that users don’t get lost and can get help if they need it.
• Training to ensure that they actually understand the why/which/what/when/who/how of the particular feature.

Unfortunately, this isn’t reality, and both organisations and users chastise each other or Microsoft for not doing things properly. Sometimes it’s not their actual faults, sometimes it actually is.

But anyway, back to shared channels.

More than meets the eye

Before shared channels was released, I shared a quiz asking what people knew about the features and restrictions. The features I asked about were merely to do with basic functionality of shared channels — not even factoring in users from external tenants.

In total there were 11 questions with a total of 20 points available. Out of 260 responses, the average score was only 10.6 — with many people responding to me on social media that the quiz was too hard. And most of the respondents were IT professionals — not even end-users, so imagine how much more challenging it can be for them.

(You can view the results here.)

Two different experiences

With shared channels in Microsoft Teams, there are effectively two different experiences that eventuate for users.

The first, is shared channels for internal use. This, is relatively innocuous and serves as another choice of whether to use an existing Team, a new Team, a private channel, a group chat, etc.

The second, is external access — where you can share channels with a user in another organisation, a Team in another organisation, and vice versa. This is where things become not just a little bit more challenging, but A LOT more challenging — if you want to do things somewhat properly that is.

Two different stories

Here’s the first challenge with shared channels. By default in Microsoft Teams, shared channels are enabled for all users, including the ability for internal users to invite external users as well as for them to join shared channels in other organisations.

The problem is that the exact opposite is configured as a default in Azure Active Directory under cross-tenant access settings.

What this results in, is a user attempting to perform a function that the application says is allowed, only to find out upon performing the action that it’s not allowed — and unfortunately with relatively vague reasons in the error message.

What a user sees

What a user thinks

Going down the rabbit hole

The problem is that this is just the start of our experience.

The relationship

The reasons why a user may not be able to invite an external user to a channel include:

• Both organisations set to block by default (Azure AD)
• Host organisation set to block by default (Azure AD)
• Host organisation set to block inbound (Azure AD)
• External organisation set to block by default (Azure AD)
• External organisation set to block outbound (Azure AD)
• Inviter not allowed to invite external users (Teams)
• Inviter not allowed to invite external users (Azure AD)
• External user not allowed to join external channels (Teams)
• External user not allowed to join external channels (Azure AD)

The problem is that it could be any permutation of these, and then there’s the added layer of being able to control the various aspects at a more granular level — by security group or individual user.

For example, you could have a policy in Teams that allows members of a particular security group to invite external users but have not set up the cross-tenant relationship in Azure AD.

Or you could have done all your bits correctly, but the other organisation hasn’t done theirs correctly.

The challenge is that before end-users can collaborate in a shared channel, the IT teams need to collaborate on setting up their relationship between organisations first.

The level of trust

And in order for external users to be able to actually upload files into a shared channel (separate from conversations), you need to enable trust settings between organisations.

Here’s the thing with trust settings… what if the external organisation has weak MFA or compliance policies?

What if they *shudder* allow SMS verification codes?

What if they allow jailbroken devices to be marked as compliant?

Getting personal

And if you want to get granular about controlling who from another organisation is allowed to come into your tenant shared channels, you can restrict this to specific users and groups:

But while that seems straightforward, wait until you get to the next screen:

When I think of an end-user trying to obtain this information from another end-user, and even having to use the term “object ID”, this is what I imagine:

Some months ago I was creating guidance for an organisation who wanted to start using shared channels, and when trying to come up with some documentation that could be provided to end users, and this is how I felt trying to explain it all:

In the end, I built a Power App to simplify the experience.

Teams Shared Channel Navigator

Yes, you read that right — it was easier for me to build an app than it was to explain the various outcomes and scenarios. Because working with shared channels, when done properly, is nothing short of a butterfly effect.

Not only did I build an app, but I also built associated workflows, AND found and worked out how to work with an undocumented/unsupported Microsoft API.

What it does

Instead of trying to explain the myriad of potential reasons why working with a shared channel may not be possible, this app simply shows the end user what they individually can or can’t do, and what is possible for the organisation.

How it works

When initially loading the app, it runs a workflow which calls an undocumented (and unsupported) Microsoft Teams API which lets us see what channel policies exist, and are assigned to the user.

(Initially I wanted to use an Azure Runbook with a PowerShell script to do it the supported way, but unfortunately the cmdlets require do not work with a combination of managed identities / service principals / application permissions — so there was no way to get the data in a secured manner.)

After a few seconds when the policies have been retrieved, the “Please wait…” text switches over to a clickable “Continue” button.

On the next screen, the application shows what the user can do based on the Microsoft Teams policies retrieved in the prior step. This is a crucial step, because not every user may have the ability to join shared channels in other organisations, or invite external people into internally hosted shared channels.

If both of those options are unavailable to the user, the text at the bottom is not visible and the “Search for an organisation” button does not appear.

If the user is able to perform either function and presses the “Search for an organisation” button, they are taken to the next screen which gives them to the option to see if a cross-tenant relationship has been established.

IMPORTANT: We can only check for our side of the process. If our side is set up correctly but the other side is not, we do not have the ability to check for that.

The user can enter either an email address of someone they wish to invite, or just the domain name of the organisation.

This calls a Microsoft Graph API endpoint which both checks to see if the partner organisation relationship has been established on our side, as well as the organisation name (as configured in their Azure Active Directory / Microsoft 365 tenant).

Based on the result it may return a negative and explain that a relationship has not been configured.

Or, if a relationship has been configured, it will identify the nature of the relationship is (ie. inbound or outbound).

If the relationship with the partner supports outbound access (i.e. the ability for users in our tenant to access channels in their tenant), the app then displays whether the user performing the search has the ability to access shared channels in the partner tenant.

This is an important step as the outbound relationship may be set to “All Users”, or may be restricted to specific individual users or security groups.

(In the below example I’ve decided to be a bit silly and show an animated GIF of Oprah Winfrey, however if the user does not have permission, it would return a “Computer says no” animated GIF from Little Britain.)

Summary

While shared channels do make it considerably easier for organisations to collaborate with each other, it’s the initial step of establishing that collaboration which can be somewhat challenging.

This solution allows users to perform some self-service discovery before contacting service desk teams to simply say “it doesn’t work” and have to begin the troubleshooting process from there.

This can reduce both the amount of frustration and time spent by all parties to get to the desired outcome of establishing collaboration between organisations and people.

And if you’re after the code, check my GitHub repository (https://github.com/loryanstrant/) as I’ll be explaining the back-end components and uploading the solution soon.

Originally published at Loryan Strant, Microsoft 365 MVP.