Your sister companies can chat, meet, and find each other like one company, without merging tenants.
Two group entities on separate Microsoft 365 tenants do not have to live on guest invitations and duplicate identities. We design and run cross-tenant synchronization, a multi-tenant organization in Teams, and per-partner access policies so people appear natively in each other's directories, keep one sign-in, and collaborate as colleagues rather than external guests.
- One identityUsers keep their home sign-in everywhere
- In the GALSister-company colleagues, findable natively
- 100Tenants a multi-tenant organization supports
- Entra ID P1The license family the features live in
What unmanaged cross-tenant life looks like inside a group.
Guest accounts everywhere, none of them governed
Each new project brings another round of invitations sent in the moment. Guests pile up in both directions until neither side can say which are still required, and when somebody leaves one company the offboarding process there has no visibility of the account they still hold at the other.
Two Teams identities per person
People switch tenants inside Teams all day, miss whatever was sent to the identity they were not signed into at the time, and end up maintaining two separate chat histories with the same colleague. Presence is unreliable, notifications arrive in the wrong place, and every meeting opens with somebody working out which account to join as.
Colleagues you cannot find in the GAL
Somebody sitting two desks away, employed by the sister company, does not appear in your address book at all. Outlook will not autocomplete their name, Teams search returns nothing, and the organization falls back to a shared spreadsheet of email addresses that has been out of date since the week it was created.
MFA prompts twice for every hop
Authentication and device claims from another tenant are not trusted unless somebody configures that trust, so a person who already satisfied their second factor at home does it again on arrival, every single time. The real cost is behavioral: repeated prompts teach people to approve without reading, which defeats the entire purpose of asking.
Leavers who linger in the other tenant
HR processes the leaver at whichever entity was paying them. The guest account at the sister company survives that entirely, still sitting in Teams channels and still holding document permissions, because no process on either side has ever claimed ownership of it.
Nobody can answer who has access to what
Put the question to either IT team, which people from the other company can reach which of our resources, and neither can answer it. The relationship accumulated one invitation at a time, so there is no design document, no scoping decision anybody made deliberately, and nothing an auditor would accept as an access attestation.
The four capabilities, designed and run as one service.
Cross-tenant synchronization, designed and built
The provisioning engine creates, updates and removes sister-company people in your directory without anybody sending anything. Our work is the design around it: which direction each flow runs, which groups scope it, how attributes map across, and what happens on deprovisioning. Then the configurations get built in each tenant so colleagues simply appear, with no invitation involved anywhere.
Multi-tenant organization in Teams
Forming the multi-tenant organization across your entities makes Teams behave as though the group were one organization. Searching for a person finds them wherever they are employed, chat and calls reach them exactly as they would an internal colleague, and the daily ritual of switching tenants to find somebody simply ends.
Cross-tenant access policies, tuned per pair
By default no external MFA or device-compliance claims are trusted, which is why sister-company users are prompted twice for everything. We configure per-organization inbound and outbound settings between your tenants, including trusting MFA and compliant-device claims where the pair's security posture justifies it.
B2B collaboration settings, tuned properly
Redemption is automated in both directions so nobody meets a consent prompt or an invitation email at all. The redemption order is set deliberately so accounts resolve to corporate identities rather than to whatever personal Microsoft account somebody once created with that address. And the defaults governing tenants outside your group stay deliberately restrictive rather than being loosened to make the internal case work.
A group-wide address book that is actually true
Attributes are mapped so a synced colleague arrives carrying their genuine job title, department and company rather than a bare display name, and appears in the address list and people search of every tenant that needs them. Finding the finance manager at the sister entity becomes a matter of typing their name, which is how it should have worked from the beginning.
Joiner and leaver flows that cross the boundary
Add a new hire to the scoping group in their home tenant and they appear in the sister directory at the next provisioning cycle. Disable a leaver at home and they are removed from every tenant they had been synced into. The lifecycle gap that guest sprawl opened up closes entirely, and it closes because a single engine now owns both the joining and the leaving.
A design that matches your group structure
Holding companies, operating entities, shared service functions and joint ventures each sit differently in a group, so who synchronizes to whom follows how the business is genuinely structured rather than a blanket everybody-to-everybody arrangement. You end up with a design document naming every flow, the reason it exists and the person who owns it.
Governance after go-live
Scoping-group reviews on a schedule, monitoring on the provisioning jobs so a silent sync failure is caught before the directories drift, changes to cross-tenant settings treated as protected and audited, and a documented unwind path in case the group structure changes again.
Four reasons groups hand this to us rather than reading the docs.
We work both tenants as one project
Roughly half these settings sit in the source tenant and half in the target, and a number of them do nothing at all unless both ends are configured to agree. We run the change across every participating tenant on one plan, in one window, with one rollback path. The alternative, which we see constantly, is two IT teams sending each other screenshots for a fortnight.
Security design first, convenience second
Trust settings, how this interacts with your access policies, and exactly what the synchronization is scoped to all get decided and written down per tenant pair before anything is switched on. That sequencing is what lets you have the good outcome, colleagues who genuinely feel internal, without the careless one sitting beside it, where every unrelated tenant quietly inherits the permissive posture you built for your own group.
We pilot on a real pair before the group commits
One source tenant, one target, a deliberately small scoping group, and then the workloads people genuinely use every day get tested: chat, meetings, reaching files, looking somebody up in the address list, how authentication behaves, and what happens when a leaver is disabled. The group-wide rollout then inherits something proven rather than something hoped for.
The Microsoft stack is our home ground
Directory, Teams, Exchange and SharePoint administration is what our engineers do daily across the tenants we manage. This particular piece of work touches all four simultaneously, which is precisely why it goes better with a partner who already operates every layer it lands on rather than one who specializes in a single product.
Closer collaboration must not become accidental full trust.
Every feature that makes sister tenants feel like a single company is also capable, if configured without thought, of handing one tenant's security weaknesses to the other. These guardrails go into the design from the start rather than being added afterward in response to something going wrong.
- Every trust decision is scoped to one organization and never applied globally. Accepting authentication and device-compliance claims from a sister tenant is usually correct within a group, but it is configured only in that tenant's own organizational settings, which means the permissive arrangement never reaches unrelated external tenants. Those keep the restrictive default they always had.
- Accepting a claim is not the same as waiving a control, and the distinction matters. Where the target tenant trusts authentication performed at the sister tenant, its own access policies still apply in their entirety. The person is simply not asked to satisfy again something they already satisfied at home. Where the sister tenant's authentication posture is weak, we raise that before configuring any trust, because trust settings import whatever weakness exists on the other side.
- How this interacts with your existing access policies gets checked before anything goes live. Policies demanding authentication registration or device compliance can combine badly with trusted external claims and lock sister-company staff out entirely. So every policy touching guests or external members is reviewed against the new trust configuration during the pilot, where a mistake affects a handful of people rather than everybody.
- Scope is always a named group and never an entire directory. Explicit groups per entity mean service accounts, contractors and long-dormant identities do not quietly appear in a sister directory where nobody expected them. What synchronizes is a decision somebody made, somebody owns, and somebody revisits on a schedule.
- The settings governing all of this are themselves governed. Changes to cross-tenant access configuration count as protected actions, can be made to require additional verification, and are written to the audit log. Widening the boundary between two tenants therefore becomes a visible act attributable to a named person rather than a toggle somebody flipped on a Thursday.
Six group structures where separate tenants must feel like one company.
Holding company with operating entities
Finance, HR and the leadership team sit in the holding tenant and deal with every operating company daily. Synchronizing operating-company staff into the holding directory, and the shared functions back in the other direction, replaces several hundred stale guest accounts with two flows somebody actually designed and owns.
Joint ventures
A JV entity with its own tenant, staffed by secondees from both parents. Synced identities give the seconded staff native presence in the JV directory while their employment, mailbox and licenses stay with the parent, and unwind cleanly if the venture ends.
Shared services entities
One entity supplies IT, finance or HR to every other company in the group. Those people need to be findable and contactable in every sister directory, and their authentication needs to be trusted by every sister tenant rather than challenged afresh at each one. Synchronization paired with trust settings delivers exactly that combination.
Practices and their management companies
This structure is distinctly American and common across healthcare and professional services: a practice entity alongside a management services organization, held legally apart for regulatory or ownership reasons while occupying the same hallway and frequently employing the same people. Synchronization running both directions, plus one shared Teams fabric, lets the pair work as the single business everybody already treats it as.
Acquisitions not yet integrated
The acquired business keeps its own tenant for anything from a year to three while integration gets planned properly. Synchronization and a multi-tenant organization give both workforces working collaboration from day one without anybody being forced into a migration decision before the analysis is done, and none of it obstructs a full merge later if that is where you land.
Family groups with independent brands
Operating businesses, property interests and an investment arm sitting under one family office, each brand on a separate tenant through history rather than through any deliberate decision. The group keeps that independence, which usually exists for good reasons, while management gets a single address book and one consistent Teams experience spanning the whole thing.
Plain guests, sync, MTO and access policies, side by side.
| Feature | Plain B2B guests | Cross-tenant sync | Multi-tenant org (Teams) | Access policies + trust |
|---|---|---|---|---|
What it is | Manual invitations, one user at a time | Automated provisioning of sister-company users into your directory | A Teams-level grouping of tenants for seamless search and chat | Per-tenant rules on who crosses the boundary and whose claims you trust |
Directory presence | Guest stub, often with a bare email for a name | Native-feeling member entry with real title, department and company | None by itself, relies on synced or invited users existing | None, it governs access rather than creating identities |
GAL and people search | Guests are typically hidden from the address book | Synced users can be listed in the GAL and found by search | People search reaches colleagues across every member tenant | Not applicable |
Teams experience | External chat with limits, tenant switching, meetings joined as guest | Better identity underneath, but Teams polish comes from the MTO layer | Chat, calls and search that feel internal, in the new Teams client | Removes the repeated MFA prompts when trust is configured |
MFA prompts across tenants | Doubled, home MFA then resource-tenant MFA again | Unchanged by itself | Unchanged by itself | Single prompt once the target trusts home-tenant MFA claims |
When someone leaves | Guest lingers until someone remembers to remove it | Deprovisioned automatically when the home account is disabled or descoped | Follows the underlying account | Not applicable, though scoping limits the blast radius |
Admin effort per person | An invitation, an acceptance and eventual cleanup, per person, forever | Zero after design, membership of a scoping group drives everything | Zero per person once the organization is formed | Zero per person, decisions are per tenant pair |
License family involved | Included in Entra ID free tier | Entra ID P1 at minimum, in both source and target tenants | Entra ID P1 family across participating tenants | Entra ID P1 for trust settings and granular scoping |
Right for | Genuine externals: auditors, vendors, short projects | Sister companies whose staff work together daily | Groups running two to one hundred tenants on Teams | Every cross-tenant relationship, group or not |
The questions we settle before anything syncs.
Decision
Who syncs in which direction
- What we work through with you
- Configurations run in one direction only, so a genuinely two-way relationship means two of them, each decided on its own merits. Frequently the sensible answer is asymmetric: everybody from the operating companies flows into the holding tenant, while only leadership and the shared functions flow back the other way.
Decision
Scoping groups per entity
- What we work through with you
- One named security group in each source tenant determines precisely who materializes in the sister directory. Whole departments can be included or excluded without ambiguity, and being added to that group becomes a governed event somebody approves rather than an automatic consequence of appearing on a payroll.
Decision
Attribute mapping
- What we work through with you
- Which fields make the journey: name, job title, department, company and phone number. Company name gets mapped deliberately rather than incidentally, so anybody reading the address list can tell that a colleague belongs to a sister entity. We also set the address-list attribute explicitly, because without it people synchronize successfully and then fail to appear anywhere useful.
Decision
Member or guest user type
- What we work through with you
- Synchronized people arrive as members by default, and most collaboration workloads treat a member as internal. We still confirm workload by workload whether that is right for your estate, because sharing policies and application behavior genuinely differ between the two states and the difference only surfaces once somebody tries to share something.
Decision
What happens on leaver
- What we work through with you
- Disable somebody at home, delete them, or simply drop them out of the scoping group, and the provisioning engine removes the corresponding account in the target tenant. This path gets tested deliberately during the pilot, because the leaver flow is the one nobody exercises and nobody notices until an auditor asks about it.
Decision
Trust settings per pair
- What we work through with you
- Which tenant extends trust to which sister tenant's for authentication and device-compliance claims, settled pair by pair rather than once for everybody. Where one security team runs the whole group, mutual trust is usually straightforward. Where entities maintain genuinely different postures, the weaker side gets raised first and trust follows afterward.
Decision
Multi-tenant organization membership
- What we work through with you
- Which tenants join, which one owns it, and whether everybody arrives together or the organization grows one piloted pair at a time. Since the platform accommodates up to a hundred tenants, whatever limits you is your appetite for governance rather than any technical ceiling.
Decision
What stays plain guest
- What we work through with you
- Plenty of people should stay outside it. External auditors, joint venture partners holding minority stakes and vendors engaged for a single project all remain governed guests with an expiry date attached. Keeping them there is what preserves the native experience as a deliberate privilege of belonging to the group rather than something everyone drifts into.
Design, pilot pair, expand, govern.
- 1
Map the group and its collaboration reality
We map every tenant in the group, the license families each holds, how many guests have accumulated in it and what its access policies currently enforce. Then the more useful question: which entities genuinely work together day to day, in which direction the traffic runs, and what the present arrangement is actually costing in wasted time. The design that follows reflects how the group operates rather than how the org chart draws it.
- 2
Design the target state on paper
Everything gets settled in writing: which flows exist and which way they run, the scoping group for each entity, how attributes map, whether synced people arrive as members or guests, trust settings for each tenant pair, who belongs to the multi-tenant organization and who owns it, and crucially what stays as plain guest access on purpose. Both IT teams and whoever owns group security sign that off before a single setting changes.
- 3
Pilot one pair of tenants
A single source tenant, a single target, and a small scoping group of genuine users rather than test accounts. Synchronization is built and verified, trust settings applied, the multi-tenant organization formed or extended, and then the workloads people actually use get tested from end to end. Search, chat, meetings, reaching files, how authentication behaves, and a deliberate leaver test to prove deprovisioning really removes access rather than appearing to.
- 4
Expand across the group
The configuration that survived the pilot goes out to the remaining pairs in a planned sequence, and each entity has its access policies reviewed against the trust design before its own flows are switched on. As every pair completes, the guest accounts the synchronization has superseded get cleaned up rather than left behind to accumulate the way they did the first time.
- 5
Govern and hand over
Provisioning health is monitored, scoping groups are reviewed on a schedule rather than when somebody remembers, and any change to cross-tenant settings is treated as protected and audited. You receive documentation covering the design itself, the runbooks and the way back. The intent is that your own teams can operate this, with us behind them for as long as that is useful.
What this does not do, said before you commit.
Reality
Licensing prerequisites
- What it means for you
- Cross-tenant synchronization needs Microsoft Entra ID P1 at minimum in both the source and target tenants. P1 ships inside the Microsoft 365 E3, E5 and Business Premium plan families and Enterprise Mobility + Security E3, so most group estates already own it, but we verify per entity before design.
Reality
Mailboxes and files stay home
- What it means for you
- A synced user's mailbox, OneDrive and licenses remain in their home tenant. Sync creates a directory presence, not a second mailbox. Cross-tenant calendar visibility is a separate Exchange configuration we set up alongside where it is needed.
Reality
Some workloads still see external
- What it means for you
- B2B member accounts are treated as internal by most collaboration surfaces, but per-application behavior varies, and some services still apply external-user rules to them. We test your actual workloads in the pilot rather than promising uniformity.
Reality
The best Teams experience needs new Teams
- What it means for you
- The multi-tenant organization experience, cross-tenant people search and seamless chat, lands in the new Teams client. Estates still holding onto classic Teams see less of the benefit until the client migration completes.
Reality
Sync is scheduled, not instant
- What it means for you
- The provisioning engine runs on a cycle measured in tens of minutes, roughly every 40 minutes, so a new joiner appears in the sister directory shortly after being added to scope, not the same second. Fine for directories, worth knowing for expectations.
Reality
Users sync, groups and devices do not
- What it means for you
- Cross-tenant synchronization provisions user accounts. It does not replicate groups, devices or contacts between tenants, so cross-tenant group membership and device trust are designed separately where they matter.
Reality
Both sides must be configured
- What it means for you
- Automatic redemption has to be enabled on the source tenant outbound and the target tenant inbound for the invitation experience to disappear, and trust settings live in each target tenant. One-sided enthusiasm produces a half-working result, which is why we run both tenants' changes as one project.
Reality
It is reversible, deliberately
- What it means for you
- Nothing merges. Disable the sync configuration and deprovision, leave the multi-tenant organization, and return access settings to defaults, and the tenants stand exactly as separate as before. We document the unwind path as part of handover.
What group IT teams ask about cross-tenant sync and collaboration.
The pages around this one.
Multi-Tenant Management
Operating many tenants day to day with Microsoft 365 Lighthouse and one group baseline.
Guest Access Governance
Sponsors, reviews and expiry for the guests who remain guests.
Microsoft Entra
The identity platform underneath: Conditional Access, B2B collaboration, and identity governance.
Tell us how many tenants your group runs, and we will map the rest.
A short review covers your entities, their license families, the current guest sprawl and the collaboration people actually need. You get a written design for sync flows, trust settings and the multi-tenant organization before anything changes.
Related Services
Explore more solutions that work great with this service
Microsoft Entra
Identity and access management solutions
Learn moreMicrosoft 365 Lighthouse
Multi-tenant visibility and baselines
Learn moreGuest Access Governance
External sharing governed, not guessed
Learn moreM365 Tenant Management
Your tenant run properly, end to end
Learn moreM365 Administration
Expert Microsoft 365 tenant management
Learn more