Shared channels in Teams are powered by B2B direct connect, the underlying technology the vendor calls Teams Connect. Both guest access and external access use a different architectural model from this one, and it repays understanding because some fundamental assumptions about how inter-tenant collaboration works are changed by it.
An external person joining your team under traditional guest access becomes a guest in your tenant. In your the identity service tenant they show up as a guest user, and your policies apply to them. With shared channels and B2B direct connect, the external user reaches the shared channel from inside their own tenant instead. No guest account exists for them in your tenant. A trust relationship is established between your tenant and theirs, and users on both sides participate in the shared channel under their own identities.
The Mechanics of B2B Direct Connect
Between two the cloud suite tenants, B2B direct connect is a mutual trust relationship. Explicitly allowing the trust relationship is required of both tenants — it does not happen automatically. Once trust is established:
- Users in Tenant A can be invited to shared channels in Tenant B's Teams, and the reverse
- Their own organisation's identity is how users appear in the shared channel (name and email drawn from their home tenant)
- Alongside their own organisation's teams, the shared channel appears in each user's Teams client
- Storage for files shared in the channel is in the channel owner's the file service
- Neither tenant has a guest account created
- For the specific partner tenant, the cross-tenant access settings must allow B2B direct connect inbound, outbound, or both. A global "allow all" is a choice, and it should be recorded as a choice rather than left sitting as a default.
- Team membership and shared channel membership are separate things. A partner able to post in the shared channel may still be unable to see the rest of the host team, which is normally the intention.
This architecture carries significant governance implications. For most purposes, the external user is governed by their own tenant's policies — their sensitivity label settings, their Conditional Access policies, their DLP policies. But the content in the shared channel resides in the host tenant's the file service, which means that content is also subject to the host tenant's retention and DLP policies.
Setting Up B2B Direct Connect
External identities > Cross-tenant access settings in the identity service admin center is where B2B direct connect is configured. Trust settings must be configured by both tenants. The configuration involves:
- Inbound settings: What will you accept from the external tenant? Their MFA claims trusted? Their device compliance claims trusted? Their users admitted into your Teams shared channels?
- Outbound settings: What will you permit for your users accessing the external tenant's resources? Are your users allowed into their Teams shared channels?
These settings can be configured globally (applying to all external tenants) or per-tenant (applying different settings to specific partner tenants). More work is required for per-tenant configuration, but better control is given for known partners.
With the cross-tenant trust established in the identity service, shared channels must also be enabled in the Teams Admin Center. Under Org-wide settings > Teams settings sits a "Shared channels" section governing whether shared channels are permitted with external tenants at all.
B2B Direct Connect or Guest Access: Which to Use
Which of the two you choose — B2B direct connect (shared channels) or traditional guest access — depends on the use case and on the relationship between the organisations.
Reach for B2B direct connect (shared channels) when:
- An established, ongoing partnership exists with another the cloud suite organisation
- Neither organisation wants to create accounts in the other's tenant, and each wants to keep its own identity
- The collaboration should feel like a peer-to-peer workspace rather than a hosted guest relationship
- The overhead of guest account lifecycle management should be avoided
Reach for guest access when:
- No the cloud suite account is held by the external collaborator (they use Gmail, for example)
- B2B direct connect has not been configured by the other organisation
- Maximum visibility and control over what the external user can access is required
- The collaboration is temporary and project-based
Shared Channels: Governance Considerations
New governance questions arrive with shared channels that traditional guest access does not raise.
Content ownership. The host tenant's the file service is where files in a shared channel are stored. Should the shared channel be deleted, those files go with it. On leaving, external users take no copy. Normally the right behaviour, but it should still be communicated to users.
Compliance policy applicability. Shared channel content is subject to the host tenant's retention and DLP policies, while the external users' home tenant policies govern their client-side behaviour. Edge cases can arise where the two tenants' compliance systems handle content differently.
Trust review process. Periodic review of the B2B direct connect trust settings in the identity service is needed, just as with guest access. Where a partner relationship ends, revoke the trust and close the shared channels with that partner.
A Shared Channel That Outlasts the Contract
Someone in another tenant can join a shared channel in Teams via B2B direct connect without becoming a guest in the host directory. Their account remains in the home tenant, and disablement, conditional access, and authentication remain with the home organisation. That split is both the feature and the governance problem: deleting a guest object is not available to the host as a way to disable the person, because no guest object exists.
A shared channel for a joint bid was opened by an engineering partnership between two firms — 1,100 people on one side, 300 on the other. The bid ended; the channel did not. Months later, staff who had left the smaller firm could still reach the channel, until their home tenant disabled the accounts. No alert reached the host team's owners when those people changed jobs. What they had was a membership list they never reviewed.
Give shared-channel membership the same calendar as guest membership. On a fixed day, owners review the list. People no longer working the engagement come off the channel even where their home account stays active. A backstop, not the process, is home-tenant disablement. When the partner is slow, the host's process still has to work.
A table suits cross-tenant access settings: partner tenant id, inbound allowed or not, outbound allowed or not, the internal owner, and the review date. Defaults that allow every tenant are easy to miss, because nothing looks "configured". A default allow is itself a configuration. Where the business wanted a named list of partners, the default is a defect.
The host team's sensitivity label and sharing constraints are also inherited by shared channels. Looser than the team that holds it, a channel cannot be. Joint work that needs a looser setting than the host team does not belong as a shared channel on that team. Instead, create a team whose label matches the joint work and put the shared channel there. Forcing the channel onto a highly restricted team and then arguing with the label is how exceptions become baked into the restricted team itself.
Establish whether the partner's conditional access will block their users from the channel. Device rules of their own apply to the partner's users, and the host has no power to waive them. The host's the file service site is where files in a shared channel live. On those files, the partner's retention rules do not displace the host's retention. Membership of the shared channel without membership of the parent team is possible. External participants are undercounted by reports that list only team members. A far bigger switch than removing one person is disconnecting a partner tenant. Be clear which of the two the request is asking for. Run the pilot with a single channel and a single partner tenant. Harder to walk back than a single channel is a tenant-wide direct-connect default. Document the support path. Where a partner cannot connect, the fault may lie in their tenant, and the host helpdesk needs the sentence that says so. Capture the partner tenant id, not just the company name. Names change; the setting stores ids. Owners who do not know a cross-tenant relationship is required can still create a shared channel. The error they encounter belongs in the support note. One partner user removed is a channel membership edit. An outage for every shared channel with that partner is what removing the tenant relationship causes. The files are covered by host-side retention. Make sure the partner understands that their downloads are their copies. Shared channels whose host team has been archived should be reviewed. Membership may still be active there. Where both organisations must agree a setting, record it in both change records on the same day. Non-production content should be used by a pilot channel until the membership review has happened once. No guest account is created by direct connect for the host to disable. The offboarding checklist must name the channel. A partner merger may change their tenant id. Old trust entries will not follow them across automatically. Put shared channels in the same monthly pack as guest counts, so external access stays one conversation. External members should be visually distinguished to owners, and that distinction should be understood as the list they must review. Recreating early is cheaper than unwinding a shared channel placed in the wrong host team once files have accumulated for a month.
