External Collaboration in Microsoft Teams: Guest Access, Shared Channels, and Clients on Slack
Sooner or later, every project puts someone from outside your organization in the loop: a client, an agency, an implementation partner, a co-contractor. Microsoft Teams gives you three ways to let them in (external access, guest access, and shared channels), and each one draws the security boundary in a different place.
Then there’s the fourth scenario nobody’s admin documentation covers: the client doesn’t use Teams at all. They live in Slack, and they have no intention of moving.
This guide walks through all four situations. For each one: what the option actually grants, where it breaks down in practice, and what changed in 2025–2026 (more than you might think). At the end, we’ll look at the part most comparisons skip — how to make whichever pattern you pick repeatable and governed instead of a one-off IT favor.
Guest access vs. shared channels vs. external access in Microsoft Teams
The three mechanisms answer three different questions. External access answers “can we talk?” Guest access answers “can you work inside our team?” Shared channels answer “can we share one workspace without you leaving your own tenant?”
Here’s the side-by-side view, based on Microsoft’s current documentation:
| External access | Guest access | Shared channels | |
|---|---|---|---|
| What they get | Chat, calls, meetings — no teams, files, or apps | Near-member access to a whole team | One channel and its dedicated SharePoint site |
| Identity | Their own account, in their own tenant | A guest account created in your Entra ID | Their own work account — nothing created in your directory |
| Tenant switching | No | Yes | No |
| Works with | Other Microsoft 365 orgs, personal Teams accounts | Anyone with a business or consumer email (Gmail included) | Microsoft Entra work or school accounts only |
| Default state | On, all domains allowed | On | Channels enabled, but B2B direct connect blocked by default |
| Setup effort | None | Low — one invitation | High — cross-tenant settings in both organizations |
If you want the deeper history of these three modes, our earlier explainer on external sharing in Microsoft Teams still holds up. What follows is the decision layer on top.
When guest access is the right choice
Guest access is the workhorse. You invite the external person by email, an account is created for them in your directory, and once a team owner adds them they can post, edit files, and join channel meetings almost like an employee. It’s the only option that works when your contact has a consumer address — a freelancer on Gmail, for instance.
Because the guest account lives in your Entra ID, it’s covered by your conditional access policies, MFA requirements, audit logs, and eDiscovery. For regulated industries, that’s the point: the external person operates inside your compliance perimeter.
The friction shows up on the guest’s side. If they already use Teams at their own company, working in your team means switching tenants, and while switched, they stop seeing notifications from their home organization. Anyone who juggles two or three client tenants a day will tell you exactly how that feels. Guests also hit real capability gaps: they can’t schedule meetings, can’t add apps, can’t access OneDrive in your tenant, and can’t invite anyone else.
Two facts admins often get wrong, because older articles still repeat stale defaults:
- Guest access has been on by default in Teams since February 2021. If you’ve never reviewed the setting, your tenant almost certainly allows it.
- Guests don’t consume Microsoft 365 licenses. They fall under Microsoft Entra External ID’s monthly-active-user billing, with a free tier (50,000 monthly active users, per Microsoft’s pricing page) that most organizations never touch.
When shared channels make more sense
Shared channels (Microsoft Teams Connect) fix guest access’s biggest complaint. The external participant sees the channel in their own Teams client, alongside their own teams: no tenant switching, no second identity, no missed notifications from home. Each shared channel gets its own SharePoint site, so files stay scoped to that channel rather than exposed team-wide.
That elegance has a price, and the price is setup. Shared channels with another company run on B2B direct connect, which is blocked by default and must be opened in both tenants. You can’t do it unilaterally. If your client’s IT team won’t touch their cross-tenant access settings, shared channels are off the table no matter what you configure. Both sides also need Entra ID P1, and participants must have work or school accounts. No Gmail.
Know the boundaries before you commit, per Microsoft’s shared channels documentation:
- A channel can be shared with up to 50 teams and hold 5,000 direct members.
- Guests (B2B accounts already in your directory) can’t be added to shared channels. This rule surprises nearly everyone the first time.
- Planner, Forms, and Stream tabs aren’t supported, and shared-channel activity doesn’t appear in missed-activity emails.
- Since January 2026, full app capabilities, including bots and message extensions, are supported in shared channels, provided the app has been updated for them. Before that, apps were the deal-breaker; if you ruled out shared channels in 2024 for that reason, it’s worth a second look.
For a scenario-by-scenario walkthrough, see our guide on when to use shared channels in Microsoft Teams.
When external access is enough
Don’t over-engineer it. If all you need is to chat and meet with people at another Microsoft 365 organization, with no files or shared workspace involved, external access already does that, and it’s on by default for all domains. A supplier check-in call doesn’t need a guest account.
The main 2025 change to know: Teams–Skype consumer interoperability ended in May 2025 along with Skype itself, and admins gained finer control, including per-user and per-group domain allow lists. If your external access policy predates that, it references settings that no longer exist.
One more 2026 update that touches all three mechanisms: the Teams admin center now has a unified External Collaboration section with preset modes (Open, Controlled, and Custom) replacing the old hunt across four admin centers. Worth knowing: Controlled mode, which matches enterprise defaults, blocks B2B direct connect. If shared channels mysteriously don’t work with a partner, this preset is a likely reason.
What to do when your clients are on Slack
All of the above assumes the other side has a Microsoft identity. But plenty of companies run entirely on Slack: agencies, startups, software vendors. And there is no native bridge. Teams external access only federates with Microsoft identities, and Slack Connect only links Slack workspaces. Even Microsoft’s official Slack-to-Teams guidance is a migration path, not an interop story — it can’t even import direct messages.
So you have three real options, and one fallback:
1. Bring them into your Teams. Invite the client as guests, or set up a shared channel if they have Microsoft 365 somewhere in their stack. This keeps everything inside your compliance boundary. The catch: you’re asking Slack-native people to work in a tool they didn’t choose, and adoption usually reflects that.
2. Meet them in their Slack. Your account managers join the client’s workspace via Slack Connect. Clients love it; your IT and compliance teams get nothing. No retention, no eDiscovery, no DLP. Multiply it by twenty clients and you’ve built shadow IT with extra steps.
3. Bridge the two platforms. Interoperability tools sync messages between a Teams channel and a Slack channel, so each side stays in its own tool. The team at Convly makes a case worth reading: Slack and Teams have each grown into a “work OS” where reporting, CRM updates, and support tickets live inside channels — which is precisely why neither side wants to leave, and why coexistence tooling exists. If both your organization and your clients have deep roots in their respective platforms, a bridge is often the most honest answer.
4. Fall back to email. It always works, and it loses everything that made channel-based collaboration worth having.
There’s no universally right answer here, but there is a universally wrong one: letting every account team improvise. Pick the sanctioned pattern (or two), write down when each applies, and make it easy to request.
Govern the pattern, not each request
Choosing between guest access, shared channels, and a Slack bridge is the easy part. The hard part is six months later: 340 guest accounts nobody remembers inviting, client workspaces that each look different because each was built by hand, and no answer to “who has access to what?”
Three controls do most of the work:
- Sensitivity labels decide the ceiling per team. A label can block guests entirely on confidential teams and restrict who can be invited to shared channels — so the decision is made once, by policy, not per request.
- Cross-tenant access settings define which partner organizations you trust for shared channels, and whether you accept their MFA claims instead of forcing re-registration.
- Access reviews put an expiry date on guest sprawl: team owners recertify their external members on a schedule, and unconfirmed guests are removed automatically.
The remaining gap is operational, and it’s the one we see most often at nBold: every client engagement needs a workspace, and if humans build those workspaces manually, they drift. Wrong naming, missing channels, no owner from the account team, guests added to the wrong places. That’s not a policy failure; it’s a provisioning failure.
This is what collaboration templates are for. Define your “client project” team once — channels, file structure, naming convention, mandatory owners, sensitivity label, guest rules — and every new engagement starts from that governed blueprint instead of a blank team. Combined with approval workflows and policies, external collaboration stops being a per-request negotiation and becomes a paved road. You can see the full pattern on our project and client delivery page, or book a demo to walk through it with your own scenarios.
Conclusion: match the mechanism to the relationship
External access for conversations. Guest access for membership. Shared channels for ongoing partnerships between Microsoft 365 organizations. A bridge when the client genuinely lives in Slack. Each mechanism is fine on its own; what hurts organizations is deciding ad hoc, one request at a time, with no template and no expiry date.
Decide the patterns once, encode them in labels and templates, and review the guests you accumulate. Eighteen months from now, when someone asks who all these external accounts belong to, you’ll have an answer.
FAQs
Do guests need a Microsoft Teams license?
No. Guest access doesn’t consume a Microsoft 365 license. Guests are billed under the Microsoft Entra External ID monthly-active-users model, and Microsoft’s pricing includes a free tier of 50,000 monthly active external users, which most organizations never exceed.
What’s the difference between guest access and shared channels?
Guest access creates an account for the external person in your Entra ID directory, gives them near-member access to a whole team, and forces them to switch tenants in Teams. A shared channel gives them access to one channel only, using their own work account: no tenant switching, no account created in your directory. In exchange, it requires cross-tenant access settings to be configured in both organizations.
Why can’t I add a guest to a shared channel?
Shared channels use B2B direct connect, not guest accounts. External participants join with their own Microsoft Entra work or school account from their home tenant. Guest accounts belong to a different mechanism (B2B collaboration), so they can’t be added to shared channels. People with consumer email addresses can’t join shared channels at all.
Do shared channels replace guest access?
No. Shared channels fit ongoing, scoped collaboration between two Microsoft 365 organizations: one channel, no tenant switching. Guest access is still the right tool when the external person needs full team membership, when they only have a consumer email address like Gmail, or when their organization won’t configure cross-tenant access.
Can Slack users chat with Microsoft Teams users?
Not natively. Microsoft Teams external access only federates with other Microsoft identities, and Slack Connect only links Slack workspaces. To work with a client on Slack, you can invite them into Teams as guests or shared-channel members, join their Slack workspace, or use a third-party interoperability bridge that syncs messages between the two platforms.