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 licence family the features live in
What unmanaged cross-tenant life looks like inside a group.
Guest accounts everywhere, none of them governed
Every project spawns another round of ad hoc invitations. Hundreds of guests accumulate across both tenants, nobody knows which are still needed, and the leaver process at one company never touches the guest account at the other.
Two Teams identities per person
Staff hop between tenants inside Teams, miss messages sent to whichever identity they are not signed into, and keep separate chat histories with the same colleague. Presence lies, notifications land in the wrong tenant, and meetings start with the join-as-guest shuffle.
Colleagues you cannot find in the GAL
The person two desks away at the sister company does not exist in your address book. Outlook cannot autocomplete them, Teams search cannot find them, and everyone falls back to a shared spreadsheet of email addresses that is always out of date.
MFA prompts twice for every hop
MFA and device claims from another tenant are not trusted by default, so a user who satisfied MFA at home does it again at the sister tenant, every time. The prompts train people to click approve without reading, which is the opposite of what MFA is for.
Leavers who linger in the other tenant
HR offboards the employee at the entity that pays them. Their guest account at the sister company survives, still inside Teams channels and still holding SharePoint permissions, because no process on either side owns it.
Nobody can answer who has access to what
Ask either IT team which sister-company users can reach which resources and the honest answer is a shrug. The relationship grew invitation by invitation, so there is no design to point at, no scoping, and no way to attest access to an auditor.
The four capabilities, designed and run as one service.
Cross-tenant synchronization, designed and built
The Entra provisioning engine creates, updates and removes sister-company users in your directory automatically. We design the direction of each flow, the scoping groups, the attribute mappings and the deprovisioning behaviour, then build the configurations in each tenant so people appear natively, without an invitation in sight.
Multi-tenant organization in Teams
We form the multi-tenant organization across your entities so Teams treats the group as one fabric: people search finds colleagues in every member tenant, chat and calls reach them like any internal colleague, and the tenant-switching ritual stops being part of the working day.
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-organisation 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
Automatic redemption on both sides so nobody sees a consent prompt or invitation email, redemption order set so accounts resolve to corporate identities rather than personal Microsoft accounts, and collaboration defaults for tenants outside the group left deliberately restrictive.
A group-wide address book that is actually true
Attribute mappings set so synced colleagues carry their real job title, department and company name, and appear in the GAL and people search of every tenant that needs them. Finding the finance manager at the sister entity becomes typing their name, the way it always should have been.
Joiner and leaver flows that cross the boundary
A new hire added to the scoping group at home appears in the sister directory on the next provisioning cycle. A leaver disabled at home is deprovisioned from every tenant they were synced into. The lifecycle gap that guest sprawl created simply closes, because one engine owns both events.
A design that matches your group structure
Holding company, operating entities, shared services, free-zone establishments: who syncs where is mapped to how the group actually works, not applied as a blanket everyone-everywhere. The design document says which flows exist, why, and who owns each one.
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
Half of these settings live in the source tenant and half in the target, and several only work when both sides are configured. We run the change across every participating tenant with one plan, one change window and one rollback, instead of two IT teams emailing screenshots at each other.
Security design first, convenience second
Trust settings, Conditional Access interplay and sync scoping are decided and documented before anything is enabled, per tenant pair. The convenient outcome, colleagues who feel internal, arrives without the careless one, unrelated tenants inheriting your group's permissive posture.
We pilot on a real pair before the group commits
One source and one target tenant, a small scoping group, and the actual daily workloads tested: chat, meetings, file access, GAL lookup, MFA behaviour, leaver deprovisioning. The group-wide rollout inherits a proven configuration rather than a hopeful one.
The Microsoft stack is our home ground
Entra, Teams, Exchange and SharePoint administration is what our engineers run all day across UAE tenants. Cross-tenant collaboration touches all four at once, which is exactly why it suits a partner who already operates every layer it lands on.
Closer collaboration must not become accidental full trust.
The same features that make sister tenants feel like one company can, configured carelessly, hand one tenant's security posture to the other. We build these guardrails into every design rather than bolting them on after an incident.
- Trust decisions stay per organisation, never global. Trusting MFA and compliant-device claims from the sister tenant is usually right inside a group, but it is configured in that tenant's organisational settings only, so the permissive posture never leaks to unrelated external tenants, which keep the restrictive default.
- Trusting a claim is not skipping the control. When the target tenant trusts sister-tenant MFA, its Conditional Access policies still apply in full; the user simply is not asked to repeat a requirement already satisfied at home. If the sister tenant's MFA posture is weak, we fix that first, because trust settings import it.
- Conditional Access interplay is checked before go-live. Policies that require MFA registration or device compliance can interact badly with trusted external claims and block sister-company users outright, so every policy touching guests and external members is reviewed against the new trust configuration in the pilot, not in production.
- Sync scope is a named group, never the whole directory. Cross-tenant synchronization is scoped to explicit groups per entity, so service accounts, contractors and dormant identities do not silently materialise in the sister directory. What syncs is a decision with an owner, reviewed on a schedule.
- The settings themselves are governed. Changes to cross-tenant access configuration are protected actions that can require additional verification, and they land in the audit log, so widening the boundary between your tenants is a visible, attributable act rather than a quiet toggle.
Six group structures where separate tenants must feel like one company.
Holding company with operating entities
Group finance, HR and leadership sit in the holding tenant and work daily with every operating company. Syncing operating-company staff into the holding directory, and shared functions back the other way, replaces hundreds of stale guests with a designed flow.
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 licences stay with the parent, and unwind cleanly if the venture ends.
Shared services entities
One entity provides IT, finance or HR to every company in the group. Its staff need to be findable and reachable in every sister directory, and trusted by every sister tenant's Conditional Access, which is precisely what sync plus trust settings deliver.
Mainland and free-zone pairs
A very UAE pattern: the mainland LLC and the free-zone establishment, separate licences and separate tenants, same owners and often the same desks. Two-way sync and a shared Teams fabric let the pair operate as the single business it really is.
Acquisitions not yet integrated
The acquired company keeps its tenant for a year or three while integration is planned. Cross-tenant sync and an MTO give day-one collaboration between the two workforces without forcing the migration decision early, and nothing done now blocks a later merge.
Family groups with independent brands
Trading, contracting, hospitality and real estate arms under one family office, each brand on its own tenant by history rather than by design. The group can keep the independence and still give management one address book and one Teams experience across all of it.
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 |
Licence 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 | What we work through with you | |
|---|---|---|
| Who syncs in which direction | Each sync configuration is one way, so a two-way relationship is two deliberate configurations. Often only some flows make sense: everyone from the operating companies into the holding tenant, but only leadership and shared functions flowing back. | |
| Scoping groups per entity | A named security group in each source tenant defines exactly who appears in the sister directory. Departments can be included or excluded cleanly, and joining the group is a governed event rather than a side effect of being hired. | |
| Attribute mapping | Which attributes travel: display name, job title, department, company name, phone. We map company name deliberately so a synced colleague is identifiable as sister-company staff in the GAL, and we set the address-list attribute so they actually appear in it. | |
| Member or guest user type | Synced users are created as B2B members by default, which most collaboration workloads treat as internal. We confirm per workload whether member is right for your estate, because sharing policies and app behaviour differ between member and guest. | |
| What happens on leaver | When a user is disabled, deleted, or drops out of the scoping group at home, the provisioning engine removes their account in the target tenant. We test this path in the pilot, because the leaver flow is the one nobody notices until an audit does. | |
| Trust settings per pair | Which tenant trusts which sister tenant's MFA and device-compliance claims, decided pair by pair. Inside a group under one security team, mutual trust is common; where entities run different security postures, trust follows the weaker side being raised first. | |
| Multi-tenant organization membership | Which tenants join the MTO, which one acts as owner, and whether every entity joins at once or the organization grows pair by pilot pair. Up to 100 tenants fit, so the constraint is governance appetite, not the platform. | |
| What stays plain guest | Not everyone belongs in the sync. External auditors, JV partners with minority stakes, and short-term project vendors stay as governed guests with expiry, so the native experience remains a deliberate privilege of being inside the group. |
Design, pilot pair, expand, govern.
- 1
Map the group and its collaboration reality
Every tenant in the group, its licence families, its existing guest population and its Conditional Access posture. Which entities actually work together daily, in which direction, and what the current pain costs. The design is grounded in how the group works, not in an org chart.
- 2
Design the target state on paper
Sync flows and their directions, scoping groups per entity, attribute mappings, member versus guest decisions, trust settings per tenant pair, MTO membership and ownership, and what deliberately stays plain guest. Signed off by both IT teams and whoever owns group security before anything changes.
- 3
Pilot one pair of tenants
One source, one target, a small scoping group of real users. Sync built and verified, trust settings applied, the MTO formed or extended, and the daily workloads tested end to end: search, chat, meetings, file access, MFA behaviour, and a deliberate leaver test to prove deprovisioning.
- 4
Expand across the group
The proven configuration is rolled to the remaining tenant pairs in a planned order, with each entity's Conditional Access reviewed against the trust design before its flows go live. Existing guest accounts that the sync supersedes are cleaned up as each pair completes.
- 5
Govern and hand over
Monitoring on provisioning health, scheduled reviews of scoping groups, cross-tenant settings changes treated as protected and audited, and documentation covering the design, the runbooks and the unwind path. Your teams can run it, and we stay behind them where wanted.
What this does not do, said before you commit.
| Reality | What it means for you | |
|---|---|---|
| Licensing prerequisites | 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. | |
| Mailboxes and files stay home | A synced user's mailbox, OneDrive and licences 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. | |
| Some workloads still see external | B2B member accounts are treated as internal by most collaboration surfaces, but per-application behaviour varies, and some services still apply external-user rules to them. We test your actual workloads in the pilot rather than promising uniformity. | |
| The best Teams experience needs new Teams | 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. | |
| Sync is scheduled, not instant | 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. | |
| Users sync, groups and devices do not | 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. | |
| Both sides must be configured | 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. | |
| It is reversible, deliberately | 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.
Tell us how many tenants your group runs, and we will map the rest.
A short review covers your entities, their licence 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
Cross-Tenant Access
Decide which partner tenants you actually trust
Entra External ID
Guests, partners and customer identity, governed
Entra Entitlement Management
Access packages that expire on their own
Entra Conditional Access
The control that decides who reaches your data
Entra ID Governance
Joiner mover leaver, access packages and guests that expire on their own
Microsoft Entra
Identity and access management solutions
M365 Administration
Expert Microsoft 365 tenant management
Microsoft Security Dubai
Entra, Defender, Purview, Sentinel, and what you already own