Official documentation checked October 14, 2026.
Microsoft Entra cross-tenant synchronization manages external identities. It does not automatically merge Microsoft 365 data or let Copilot search every synchronized person’s source-tenant mailbox and files. Use it for an approved identity-collaboration requirement, then verify resource access and the exact Copilot capability separately.
This distinction matters in a merger or multitenant organization: a successful provisioning job is not proof of cross-tenant Copilot grounding, a data migration or a compliance assessment.
What Cross-Tenant Synchronization Actually Does
The current Microsoft overview describes an Entra provisioning-engine process that pushes identities from a source tenant into a target tenant. It supports users and supported groups; it is not an Azure AD Connect or Microsoft Identity Manager configuration for copying Microsoft 365 content.
A synchronized identity can participate in supported B2B collaboration. Its userType can be Member or Guest according to the configuration; “B2B collaboration” is not the literal value to expect in that field. The source remains relevant to authentication.
Keep three acceptance tests separate: identity creation, authorized access to a specific resource, and successful use of that resource by a supported Copilot feature. Passing the first test does not imply either of the others.
Check Licensing, Ownership and Data Access First
For same-cloud user synchronization, Microsoft specifies Entra ID P1 for each synchronized source user. Group and cross-cloud scenarios have different Governance or Entra Suite requirements. The target does not need a synchronization license merely to receive the identity, but services used there may have their own requirements.
These identity requirements are separate from Copilot licensing. A personal subscription is not a replacement for an organization’s required entitlement, and a paid organizational license does not establish that every external-user scenario is supported.
Before configuration, document the source and target tenant IDs, authorized administrators, pilot users, business purpose and intended resource. The owners of both tenants should approve the trust relationship. For separate organizations, obtain a privacy and security review of the identity information being shared.
Review cross-tenant access settings and workload sharing rules without changing them to “allow everyone.” Identity synchronization, sign-in authorization, file permissions and feature support are different controls.
Pilot the Documented Identity Configuration
Use Microsoft’s configuration procedure for your cloud and scenario. It identifies the required roles and the settings in each tenant. A small approved pilot should establish:
- Target acceptance: the intended source organization is configured and inbound user synchronization is allowed for that relationship. Enable group synchronization only if that is part of the approved design.
- Invitation redemption: configure the required automatic-redemption settings for the source’s outbound and target’s inbound relationship. This is not consent to every application or access to all data.
- Source configuration: create the synchronization configuration, select a limited assignment scope and review attribute mappings. Do not rename users merely to force a job through an unexplained error.
- On-demand test: provision a pilot identity and inspect the provisioning result and target object. Verify the expected identity attributes before starting or expanding scheduled provisioning.
Plan lifecycle changes before broad rollout. Removing someone from scope can affect the target identity and their access; synchronization is not simply an address-book export.
Validate Copilot Separately and Investigate the Right Layer
Use a nonsensitive test file with approved sharing. Confirm the intended user and tenant context, and open the file directly. Then check the requirements for the specific Copilot experience and test only a documented source-access path. Record whether the feature accepts the source and whether its citation points to the correct file.
If provisioning fails, inspect the source job’s logs and object mapping. If direct access fails, investigate the resource’s sharing and applicable sign-in policy. If direct access works but Copilot cannot use the source, investigate that feature’s external-source limitations. Do not change unrelated identity trust to compensate for an unsupported retrieval scenario.
There is no general Microsoft 365 admin-center “Cross-tenant data sharing” toggle established by this procedure that enables all Copilot access to synchronized users’ data. Do not treat account creation as permission to search another person’s mailbox.
If the business needs centralized data rather than identity collaboration, design that as a separate migration or approved integration project. Document where content and prompts are processed; leaving the original file in its source tenant is not, by itself, a complete data-residency guarantee.