Two distinct mechanisms for external collaboration are supported by Teams, and grasping the difference between them is foundational to designing your external collaboration policy.
Guest access places an external person into a specific team as a guest. A guest account is created for them in your the identity service tenant, the team appears in their own Teams client, and they can take full part in that team's channels and meetings. Deep and persistent, guest access creates an ongoing relationship between your tenant and the external user.
External access (federation) lets Teams users search for, call, and chat with users in other the cloud suite tenants without adding them as guests. A lighter-weight, peer-to-peer communication mechanism is what this is. Users communicate under their Teams identity, yet no account is created in either tenant. Broad and transient, external access applies by default to all external Teams users rather than to specific individuals.
Cases for Guest Access
Guest access fits when:
- The external person requires ongoing, persistent access to a team's files and channels
- Project-based collaboration with an external team will run over weeks or months
- Exact control is needed over which external people may access specific content
- The collaboration needs DLP, sensitivity labels, or compliance recording applied to it
- Only a one-off file is needed by the external person, with no ongoing membership and no reason to see channel history.
- Both organisations run Teams and want a shared channel without a guest account in either directory.
Administrative overhead is the trade-off with guest access: guest accounts must be created and managed, a process is needed for removing guests once the collaboration ends, and each guest is an ongoing security and compliance touchpoint.
Cases for External Access
External access fits when:
- Users need ad-hoc communication with known contacts at other organisations
- No ongoing team-based collaboration exists — only calling and messaging
- The other organisation is a trusted partner with no need to access your content
- Communication should be enabled without accounts being created in your tenant
Coarser control is the trade-off with external access: federation with all the cloud suite tenants is permitted by default. Restriction to specific allowed domains is possible, but granularity sits at the domain level, not with the individual user.
How External Access Is Configured
Teams Admin Center > Org-wide settings > External access is where the external access settings live. The main options:
- Allow all external domains: Anyone in any the cloud suite tenant that also permits external communication can be contacted by users. Both the default and the most permissive setting.
- Allow only specific external domains: Communication with your users is limited to users from explicitly listed domains. Reach for this when federation should be restricted to known partners.
- Block specific external domains: All federation is allowed except for the listed domains. Use this where known problematic external domains must be blocked while general federation continues.
- Block all external domains: External federation is stopped entirely. Communication is confined to your own tenant.
Shared Channels as the Alternative
A third external collaboration mechanism was introduced by the vendor: shared channels (Teams Connect). Users from different tenants can collaborate in a single channel that shows up in each organisation's Teams client. No guest account is needed in the other tenant — users participate as themselves, which distinguishes this from guest access. And unlike external access, the collaboration takes place in a structured channel with full Teams functionality.
A significant architectural change in how inter-tenant collaboration works is represented by shared channels. B2B direct connect (covered separately) is the underlying mechanism they use. For many enterprise collaboration use cases, the experience is better than traditional guest access, particularly for long-running partnerships where each organisation wants to keep its own identity and governance.
Drafting Your External Collaboration Policy
A few questions to settle when designing your external collaboration policy:
Is there regulated data you hold that shouldn't leave your tenant? If so, caution is needed with both guest access and external access. Teams DLP policies help, but a thoughtful external collaboration policy cannot be replaced by them.
Are there specific partners you collaborate with regularly? If so, consider guest access for those partners, with external access restricted to their domains only. More control than open federation is what this gives you.
How will cleanup of guest accounts be assured? Allow guest access at scale and a lifecycle process is required. Without one, guest accounts accumulate indefinitely.
Are your users clear about which mechanism to use? To most end users, the difference between guest access and external access is not obvious. Training and clear guidance on when to use each mechanism cut down ad-hoc, governance-bypassing workarounds.
Federation Left Ajar Because a Single Partner Asked
The federation switch, external access, is tenant-wide in spirit even when an allow list attempts to narrow it. Open federation so one partner can chat and then forget the allow list, and any external Teams user may message staff who are also permitted by messaging policy to chat externally. Specific was the partner request. The resulting configuration frequently is not.
External access was enabled by a 90-person architecture studio for a single joint venture, with no restriction on the domain list. Inside a month, staff were in federated chats with recruiters and with a former collaborator whose domain had never been approved. Nothing in the Teams admin center flagged those chats as wrong, since the org-wide setting allowed them and the messaging policy allowed the users. The allow list was the control that got skipped, because the joint venture was in a hurry.
Draft the allow list before the switch is set to on. Not ready is the request, if the list cannot be produced. Each domain should carry a review date and an internal owner. Domains leave the list when the contract ends, not when somebody remembers. An access path with no business owner is what a domain left behind after the contract becomes.
Different requests are answered by external access and guest access, and swapping one for the other produces the wrong kind of access. Between two tenants, federation is a conversation. Inside yours, guest access is membership. A partner who must edit files in a channel is a guest or a shared-channel participant, never a federated chat contact. Federation offered because guest approval feels slow is how files end up pasted into a chat with no team, no label, and no expiration.
A third path is shared channels through B2B direct connect, and they need their own allow relationship in the identity service. Configuring that relationship is not done by turning on external access. Staff will report "external Teams is broken" once they have been told to use a shared channel nobody set up. Each scenario should have its path named in one line in the policy document: chat only, file collaboration inside our team, or a shared channel. Undecided is the scenario, if that line cannot be written.
Before announcing federation, test it with an account in a tenant you control. Cheaper than a failed client call is a failed test. Partners will still see them as unreachable even though messaging policy blocks users from external chat. A feature, that — and support staff need the sentence that explains it. Different external-access switches are followed by consumer accounts and organisational accounts. Check both where the partner is a small firm on a personal subscription. Note the date each domain was added. Review is impossible for an allow list without dates. Never describe external chat as private. Their copy of the conversation falls under the other organisation's retention and eDiscovery rules. Where a domain must be blocked rather than merely left off an allow list, use the block list and record the reason. Different signals to the next administrator are omission and block. Read the allow list aloud to whoever requested the partner. A missing domain will be noticed by them faster than by an admin. Chats may keep arriving under the old name for a while from a domain acquired by another company. Decide whether the old domain remains. Your retention schedule does not cover the partner's copy of the chat under external access. That sentence belongs in the approval. The allow list will not override messaging policy where it blocks external chat for a department. Verify both before telling the partner to try again. Block lists and allow lists kept by different people will contradict each other. Assign a single owner to both. Where a joint venture ends on a known date, that date should sit on the domain row when the row is created. Test a chat from the partner to a user who should be blocked, not just to one who should succeed. Do not enable all external domains for a weekend intending to tighten on Monday. The unexpected chat starts on weekends. Record which path was refused and why, so the next request does not relitigate a decision already made. In effect, federation changes are tenant-wide even when one team made the request. Above that team should sit the approval. Once the allow list is saved, export it and attach the export to the change ticket, so the approved domains are not visible only in the portal.
