LearnMicrosoft Teams › 13 · Architecture & advanced operations

Multi-tenant organizations (MTO)

MTO makes several tenants FEEL like one company — unified search, cross-tenant chat and presence — by synchronising identities, not by merging anything. Know exactly what it unifies and what it deliberately does not.

The construction

An MTO is a declared group of tenants (one owner, joiners) wired together by two machines:

  1. Cross-tenant synchronization (Entra): users from tenant A materialise as B2B members in tenant B (and vice versa per your topology) — provisioned automatically, attribute-mapped, lifecycle-synced. These are real directory objects; licensing/CA in the HOST tenant applies to them.
  2. MTO trust configuration: the tenant group declaration plus the cross-tenant-access trust settings (accept each other's MFA etc. — the B2B module's machinery, now at org scale).

On top, Teams delivers the FEEL: people search finds colleagues across member tenants, chat/calls reach them without tenant switching (improved external experience rather than the guest-switch dance), presence flows.

What stays separate (say this in the design review)

Policies, meetings capabilities, compliance boundaries, phone systems, app catalogs — EVERY tenant keeps its own. A user syncs INTO your directory but their meetings still run on their home tenant's policies; eDiscovery still follows the hosting-tenant rules per artifact (shared channels' host rule, chats' both-sides rule). MTO is a usability fabric over sovereign tenants — it is NOT a migration, and selling it internally as 'merging Teams' creates the expectations you'll spend a year managing.

Scale/licensing notes: member-tenant counts and sync scale have product limits (check current); cross-tenant sync needs appropriate Entra licensing per synced identity.

What to watch (proofs)

  • The sync machinery's health: Entra > Cross-tenant synchronization — provisioning status, per-user errors, attribute-mapping config; failed provisioning = the colleague who's invisible in search, with a named error.
  • The trust contract: cross-tenant access settings per member tenant (inbound/outbound + trust toggles) — export the matrix; it IS the MTO's security posture.
  • The lived experience test: from each member tenant — search a remote colleague, chat them, check presence — the three-step acceptance run after every topology change.
  • Where the seams show: a cross-tenant user's meeting join (whose lobby rules fired?) and an eDiscovery dry run across a cross-tenant chat — the two seam demos that keep expectations honest.

PowerShell for this concept

Discussion

No messages yet — start the thread.

Sign in with your email to join the discussion — we send a one-time link, no password.