Microsoft Teams supports two distinct mechanisms for external collaboration, and understanding the difference between them is foundational to designing your external collaboration policy.
Guest access adds an external person to a specific team as a guest. They get a guest account in your Entra ID tenant, they see the team in their own Teams client, and they can participate fully in that team's channels and meetings. Guest access is deep, persistent, and creates an ongoing relationship between your tenant and the external user.
External access (federation) allows Teams users to search for, call, and chat with users in other Microsoft 365 tenants without adding them as guests. It's a lighter-weight, peer-to-peer communication mechanism. Users communicate with their Teams identity, but there's no account created in either tenant. External access is broad and transient — it applies to all external Teams users by default, not specific individuals.
When to Use Guest Access
Guest access is appropriate when:
- The external person needs persistent, ongoing access to a team's channels and files
- You're doing project-based collaboration with an external team over weeks or months
- You need to control exactly which external people can access specific content
- You need to apply DLP, sensitivity labels, or compliance recording to the collaboration
- The external person only needs a one-off file, with no ongoing membership and no reason to see channel history.
- The relationship is between two organisations that both run Microsoft Teams and want a shared channel without a guest account in either directory.
The trade-off with guest access is administrative overhead: you create and manage guest accounts, you need a process for removing guests when the collaboration ends, and each guest represents an ongoing security and compliance touchpoint.
When to Use External Access
External access is appropriate when:
- Users need to communicate ad-hoc with known contacts at other organisations
- There's no ongoing team-based collaboration — just messaging and calling
- The other organisation is a trusted partner that doesn't need access to your content
- You want to enable communication without creating accounts in your tenant
The trade-off with external access is less granular control: by default, it allows federation with all Microsoft 365 tenants. You can restrict it to specific allowed domains, but the granularity is at the domain level, not the individual user level.
Configuring External Access
External access settings are in Teams Admin Center > Org-wide settings > External access. The main options:
- Allow all external domains: Users can communicate with anyone in any Microsoft 365 tenant that also allows external communication. This is the default and most permissive setting.
- Allow only specific external domains: Only users from explicitly listed domains can communicate with your users. Use this when you want to restrict federation to known partners.
- Block specific external domains: Allow all federation except for listed domains. Use this to block known problematic external domains while allowing general federation.
- Block all external domains: No external federation. Users can only communicate within your tenant.
The Shared Channels Alternative
Microsoft has introduced shared channels (Teams Connect) as a third external collaboration mechanism. Shared channels allow users from different tenants to collaborate in a single channel that appears in each organisation's Teams client. Unlike guest access, users don't need a guest account in the other tenant — they participate as themselves. Unlike external access, the collaboration happens in a structured channel with full Teams functionality.
Shared channels represent a significant architectural change in how inter-tenant collaboration works. They use B2B direct connect (which we cover separately) as the underlying mechanism. For many enterprise collaboration use cases, shared channels provide a better experience than traditional guest access, especially for long-running partnerships where each organisation wants to maintain its own identity and governance.
Building Your External Collaboration Policy
A few questions to answer when designing your external collaboration policy:
Do you have regulated data that shouldn't leave your tenant? If yes, be cautious with both guest access and external access. DLP policies in Teams help, but they don't replace a thoughtful external collaboration policy.
Do you have specific partners you collaborate with regularly? If yes, consider using guest access for those partners and restricting external access to their domains only. This gives you more control than open federation.
How will you ensure guest accounts are cleaned up? If you allow guest access at scale, you need a lifecycle process for it. Without that, guest accounts accumulate indefinitely.
Are your users clear on which mechanism to use? The difference between guest access and external access is not obvious to most end users. Training and clear guidance on when to use each mechanism reduces ad-hoc, governance-bypassing workarounds.
Federation Left Open Because One Partner Asked
External access, the federation switch, is tenant-wide in spirit even when an allow list tries to narrow it. Opening federation so one partner can chat, and then forgetting the allow list, lets any external Microsoft Teams user message staff who are also allowed to chat externally by messaging policy. The partner request was specific. The resulting configuration often is not.
A 90-person architecture studio enabled external access for a single joint venture and did not restrict the domain list. Within a month, staff were in federated chats with recruiters and with a former collaborator whose domain was never approved. Nothing in the Teams admin center marked those chats as wrong, because the org-wide setting allowed them and the messaging policy allowed the users. The allow list was the control that had been skipped because the joint venture was in a hurry.
Write the allow list before the switch is set to on. If the list cannot be produced, the request is not ready. Include a review date and the internal owner of each domain. Domains leave the list when the contract ends, not when someone remembers. A domain that remains after the contract is an access path with no business owner.
External access and guest access answer different requests, and substituting one for the other creates the wrong kind of access. Federation is a conversation between two tenants. Guest access is membership inside yours. A partner who must edit files in a channel is a guest or a shared-channel participant, not a federated chat contact. Offering federation because guest approval feels slow is how files end up pasted into a chat that has no team, no label, and no expiration.
Shared channels through B2B direct connect are a third path and need their own allow relationship in Entra ID. Turning on external access does not configure that relationship. Staff will report that "external Teams is broken" when they have been told to use a shared channel that nobody set up. The policy document should name the path for each scenario in one line: chat only, file collaboration inside our team, or a shared channel. If the line cannot be written, the scenario is not decided.
Test federation with an account in a tenant you control before announcing it. A failed test is cheaper than a failed client call. Users blocked from external chat by messaging policy will still appear to partners as unreachable. That is a feature, and support staff need the sentence that explains it. Consumer accounts and organisational accounts follow different external-access switches. Check both if the partner is a small firm on a personal subscription. Log the date each domain was added. An allow list without dates cannot be reviewed. Do not describe external chat as private. The other organisation's retention and eDiscovery rules apply to their copy of the conversation. If a domain must be blocked rather than merely omitted from an allow list, use the block list and record the reason. Omission and block are different signals to the next administrator. Read the allow list out loud to the person who requested the partner. They will notice a missing domain faster than an admin will. A domain acquired by another company may keep sending chats under the old name for a while. Decide whether the old domain stays. External access does not put the partner under your retention schedule for their copy of the chat. Include that sentence in the approval. If messaging policy blocks external chat for a department, the allow list will not override it. Check both before telling the partner to try again. Block lists and allow lists maintained by different people will contradict. One owner for both. A joint venture that ends on a known date should have that date on the domain row when the row is created. Test a chat from the partner to a user who should be blocked, not only to a user who should succeed. Do not enable all external domains for a weekend and plan to tighten on Monday. Weekends are when the unexpected chat starts. Write down which path was refused and why, so the next request does not relitigate a decision that was already made. Federation changes are tenant-wide in effect even when the request came from one team. The approval should sit above that team. After the allow list is saved, export it and attach the export to the change ticket so the approved domains are not only visible in the portal.
