Teams shared channels vs standard channels

Shared channels were introduced to solve a specific problem — collaborating with people who aren't members of the team, including people in other tenants, without making them join the team or switch tenants — and they solve it well. What they also do is introduce a second membership model, a second file location, and a list of features that don't work, and most of the surprise tickets come from people who created a shared channel because it sounded flexible. This guide is the comparison against a standard channel, feature by feature, with the trade-offs stated plainly. The private vs shared channels guide covers the privacy angle; this one is about the day-to-day differences.

Membership

A standard channel has no membership of its own: everyone in the team sees it. Add someone to the team and they see every standard channel; remove them and they lose all of them.

A shared channel has its own membership, independent of the team. Members can be people in the team, people in the organisation who aren't in the team, and — with B2B direct connect configured in Entra cross-tenant access settings — people in other organisations, who see the channel in their own Teams client without switching tenants. A shared channel can also be shared with an entire team (yours or another tenant's), whose members then all get access.

The consequences:

• Team membership doesn't govern shared channels. Removing someone from the team does not remove them from a shared channel they were added to directly. Offboarding has to consider both.
• External members don't become guests. They're not in your directory as guest objects; they're authenticated by their home tenant under a B2B direct connect trust. This is cleaner than guest sprawl and it's also invisible to processes that inventory guest accounts.
• Owners are per channel. The team owner isn't automatically an owner of a shared channel created in their team; the channel creator is. Orphaned shared channels (creator leaves) are a known problem.

Files

Standard channel files live in a folder in the team's SharePoint site. Shared channel files live in a separate SharePoint site created for the channel, with its own permissions synced to channel membership. That site is a "channel site" tied to the parent team site, but it's distinct, and it's the reason shared-channel files don't appear in the team's document library and don't inherit the team site's metadata, content types, or retention labels applied at the library level.

Sensitivity labels applied to the team are inherited by the shared channel's site, and external sharing settings on the parent determine what's possible. But anything configured on the team site's library — columns, views, flows — needs configuring again on each shared channel site. Organisations with heavily customised team sites feel this.

What's missing in shared channels

The list has shrunk since launch but is still real. As of recent releases, shared channels lack or limit:

• Some apps and bots: many Teams apps support shared channels now, but not all; third-party apps in particular may not. Test the ones your team relies on.
• Meetings: channel meetings in shared channels are supported now, but historically weren't, and scheduling and recording behaviour differs for external members.
• Planner, Loop components, and some tabs: availability has improved; check the current state for the specific tab.
• Copilot behaviour with external members: external participants use their home tenant's Copilot (if any) and can't ground on your content beyond the channel.
• Moving or converting: you can't convert a standard channel to shared or vice versa; you create a new one and migrate.
• Nesting: a shared channel can't be shared with a private channel or another shared channel.
• Limits: a team can have a bounded number of shared channels (and private channels), and a shared channel a bounded number of members and shared teams. The numbers are generous but finite; check the current service limits for anything large.

The honest summary: shared channels get closer to standard channels every quarter, but anything unusual — a custom app, a bespoke SharePoint library, a specific compliance feature — needs to be verified before you commit a project to a shared channel.

The cross-tenant dependency

Cross-organisation shared channels require both tenants to enable B2B direct connect for each other in Entra's cross-tenant access settings — inbound and outbound, with the specific applications (Office 365) allowed — and Teams' own policy to permit shared channels with external participants. If either side hasn't configured it, the invite silently fails or the option doesn't appear. That's an identity-admin task, not a Teams-admin one, and it's the number-one reason "shared channels with our partner don't work." The cross-tenant access settings guide covers the configuration; from the Teams side, the point is that shared channels are only as available as your Entra settings make them.

When to create which

Standard channel when the audience is the team. It's simpler, the files are where everyone expects them, and every feature works. Most channels should be standard; the temptation to make everything shared "just in case" creates governance debt.

Shared channel when:

• The channel's audience is genuinely different from the team's — a cross-functional workstream, a vendor relationship, a project with a partner organisation.
• You'd otherwise create a whole new team just to include a few outsiders.
• External collaborators would otherwise need guest accounts, and both tenants have B2B direct connect.

Private channel when the audience is a subset of the team and needs confidentiality. Private channels also have their own site and their own gaps; they're not a substitute for shared.

Governance checklist

1. Decide who may create shared channels (Teams policy) and whether external participation is allowed, per group of users.
2. Configure B2B direct connect deliberately, per partner tenant, not "allow all."
3. Include shared channel sites in SharePoint governance — they're separate sites and they multiply.
4. Add shared channels to offboarding: team removal doesn't cover them.
5. Assign a second owner to every shared channel. Orphans are common.
6. Document the feature gaps that matter to your organisation so people know before they create one.

Shared channels are the right answer to a real problem. The wrong use of them is as a default — a standard channel that happens to be shareable. Treat them as a specific tool for a specific audience shape, and the surprises mostly disappear.