B2B direct connect is the underlying technology that powers shared channels in Microsoft Teams — what Microsoft calls Teams Connect. It's a different architectural model from both guest access and external access, and it's worth understanding because it changes some fundamental assumptions about how inter-tenant collaboration works.
With traditional guest access, when an external person joins your team, they become a guest in your tenant. They show up in your Entra ID tenant as a guest user. Your policies apply to them. With B2B direct connect and shared channels, the external user accesses the shared channel from within their own tenant. They don't have a guest account in your tenant. Your tenant and their tenant establish a trust relationship, and users from both sides participate in the shared channel using their own identities.
How B2B Direct Connect Works
B2B direct connect is a mutual trust relationship between two Microsoft 365 tenants. Both tenants need to explicitly allow the trust relationship — it's not automatic. Once the trust is established:
- Users from Tenant A can be invited to shared channels in Tenant B's Teams, and vice versa
- Users appear in the shared channel with their own organisation's identity (name and email from their home tenant)
- Each user's Teams client shows the shared channel alongside their own organisation's teams
- Files shared in the shared channel are stored in the channel owner's SharePoint
- No guest account is created in either tenant
- The cross-tenant access settings must allow B2B direct connect inbound, outbound, or both, for the specific partner tenant. A global "allow all" is a choice, and it should be written down as a choice rather than left as a default.
- Shared channel membership is separate from team membership. A partner who can post in the shared channel may still be unable to see the rest of the host team, which is usually the point.
The governance implications of this architecture are significant. The external user is governed by their own tenant's policies for most purposes — their DLP policies, their Conditional Access policies, their sensitivity label settings. But the content in the shared channel lives in the host tenant's SharePoint, which means the host tenant's retention and DLP policies also apply to that content.
Configuring B2B Direct Connect
B2B direct connect is configured in the Entra ID admin center under External identities > Cross-tenant access settings. Both tenants need to configure trust settings. The configuration involves:
- Inbound settings: What do you allow from the external tenant? Trust their MFA claims? Trust their device compliance claims? Allow their users into your Teams shared channels?
- Outbound settings: What do you allow for your users accessing the external tenant's resources? Allow your users to access their Teams shared channels?
You can configure these settings globally (apply to all external tenants) or per-tenant (apply different settings to specific partner tenants). Per-tenant configuration is more work but gives better control for known partners.
Once the cross-tenant trust is established in Entra ID, you also need to enable shared channels in the Teams Admin Center. Under Org-wide settings > Teams settings, there's a "Shared channels" section where you can control whether shared channels are allowed with external tenants at all.
When to Use B2B Direct Connect vs Guest Access
The choice between B2B direct connect (shared channels) and traditional guest access depends on the use case and the relationship between the organisations.
Use B2B direct connect (shared channels) when:
- You have an established, ongoing partnership with another Microsoft 365 organisation
- Both organisations want to maintain their own identity and don't want to create accounts in each other's tenant
- The collaboration needs to feel like a peer-to-peer workspace, not a hosted guest relationship
- You want to avoid the guest account lifecycle management overhead
Use guest access when:
- The external collaborator doesn't have a Microsoft 365 account (they use Gmail, for example)
- The other organisation hasn't configured B2B direct connect
- You need maximum visibility into and control over what the external user can access
- The collaboration is project-based and temporary
Governance Considerations for Shared Channels
Shared channels introduce new governance questions that traditional guest access doesn't have.
Content ownership. Files in a shared channel are stored in the host tenant's SharePoint. If the shared channel is deleted, those files go with it. The external users don't take a copy when they leave. This is usually the right behaviour, but it should be communicated to users.
Compliance policy applicability. The host tenant's retention and DLP policies apply to shared channel content. The external users' home tenant policies apply to their client-side behaviour. This can create edge cases where content is handled differently by the two tenants' compliance systems.
Trust review process. The B2B direct connect trust settings in Entra ID should be reviewed periodically, just like guest access. If a partner relationship ends, the trust should be revoked and shared channels with that partner closed.
A Shared Channel That Outruns the Contract
B2B direct connect lets someone in another tenant join a shared channel in Microsoft Teams without becoming a guest in the host directory. The account stays in the home tenant. Authentication, conditional access, and disablement stay with the home organisation. That split is the feature, and it is also the governance problem: the host cannot disable the person by deleting a guest object, because there is no guest object.
An engineering partnership between two firms, 1,100 people on one side and 300 on the other, opened a shared channel for a joint bid. The bid ended. The channel did not. Months later, staff who had left the smaller firm still reached the channel until their home tenant disabled the accounts. The host team's owners had no alert when those people changed jobs. They had a membership list they did not review.
Treat shared-channel membership with the same calendar as guest membership. Owners review the list on a fixed day. People who no longer work the engagement come off the channel even if their home account is still active. Home-tenant disablement is a backstop, not the process. The host's process has to work when the partner is slow.
Cross-tenant access settings deserve a table: 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 a configuration. If the business wanted a named list of partners, the default is a defect.
Shared channels also inherit the host team's sensitivity label and sharing constraints. A channel cannot be looser than the team that holds it. If the joint work needs a looser setting than the host team, it does not belong as a shared channel on that team. 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 get baked into the restricted team itself.
Confirm whether the partner's conditional access will block their users from the channel. Their device rules apply to their users, and the host cannot waive them. Files in a shared channel live in the host's SharePoint site. The partner's retention rules do not replace the host's retention on those files. A user can be in the shared channel and not in the parent team. Reports that only list team members undercount external participants. Disconnecting a partner tenant is a bigger switch than removing one person. Know which one the request is asking for. Pilot with one channel and one partner tenant. A tenant-wide direct-connect default is harder to walk back than a single channel. Write the support path. When a partner cannot connect, the fault may be in their tenant, and the host helpdesk needs the sentence that says so. Record the partner tenant id, not only the company name. Names change and ids are what the setting stores. A shared channel can be created by an owner who does not know a cross-tenant relationship is required. The error they see should be in the support note. Removing one partner user is a channel membership edit. Removing the tenant relationship is an outage for every shared channel with that partner. Host-side retention covers the files. Confirm the partner understands their downloads are their copies. Review shared channels whose host team has been archived. Membership may still be live. If both organisations must agree a setting, write the setting in both change records on the same day. A pilot channel should use non-production content until the membership review has happened once. Direct connect does not create a guest account to disable. The offboarding checklist has to mention the channel by name. When a partner merges, their tenant id may change. Old trust entries will not follow them automatically. List shared channels in the same monthly pack as guest counts so external access is one conversation. Owners should see external members visually distinguished and know that distinction is the list they must review. A shared channel created in the wrong host team is cheaper to recreate early than to unwind after files have accumulated for a month.
