Cross-tenant synchronization is primarily a Microsoft Entra identity-provisioning capability, not a setting inside Microsoft Teams. The distinction matters because Teams offers several forms of external collaboration. Entra cross-tenant synchronization creates and maintains B2B collaboration identities in a target tenant; Teams shared channels use B2B direct connect, a separate identity mechanism with different trust and access behavior. Both can exist in an organization’s collaboration design, but configuring one does not automatically configure or validate the other.
This article retains its original Teams-oriented title because organizations often first notice the problem when employees cannot collaborate across tenants. A realistic example is a company with two Microsoft 365 tenants after an acquisition. Employees need to find certain colleagues, access approved applications and participate in Teams workspaces without uncontrolled manual account creation. An administrator must decide whether the scenario calls for synchronized B2B collaboration accounts, shared-channel direct connect, ordinary guest invitations or a combination. The right choice depends on the resources, lifecycle, security rules and user experience needed.
Understand the three collaboration mechanisms before configuring anything
Microsoft Entra B2B collaboration allows a user from one organization to access applications and resources in another tenant under a corresponding external-user identity. A guest may be invited manually, or an organization may manage those B2B identities through automated provisioning. Permissions are still determined by the resource tenant and the specific application. Simply having an account in a directory does not authorize access to every Team, SharePoint site, application or file.
Cross-tenant synchronization automates creating, updating and deleting or deprovisioning eligible B2B collaboration identities across tenants. Microsoft describes it as a provisioning process initiated from the source tenant; it is not a data or mailbox migration. The home/source identity remains necessary to authenticate, and synchronized users do not automatically bring their Teams conversations, OneDrive content or SharePoint documents with them. Moving the underlying user data requires separate planning and supported migration tools.
Teams shared channels are different. External participants can use B2B direct connect, which relies on mutual cross-tenant trust configuration rather than creating a conventional B2B collaboration user object in the resource tenant. A direct-connect participant is granted access to a particular shared channel, not automatically to the parent Team or every resource in the destination organization. A normal Teams guest in a standard Team behaves differently. This is why a successful synchronization job is not proof that a shared-channel invitation should work.
For a comparison of operational roles and collaboration administration, Microsoft Teams administration provides context for governance and user experience. But MS-700 knowledge does not turn Entra provisioning into a Teams-only feature. The article’s central decision is architectural: choose the identity model that corresponds to the collaboration requirement and verify the resource permissions separately.
Design the source, target and user scope explicitly
A pilot should begin by naming the source tenant, target tenant and the people who own their respective policies. In the acquisition scenario, one tenant may hold employees’ home identities while the other hosts a business application and Teams resources. List exactly which employees need which resources, for how long, and who will approve their access. Broadly synchronizing all employees without a documented business purpose can increase the number of external identities that need monitoring and lifecycle controls.
Entra cross-tenant synchronization uses the provisioning engine. The source tenant contains the synchronization configuration, attribute mapping and population in scope. The target tenant permits inbound synchronization for the relevant organization. The process pushes eligible source users into the target; it is not a pull job defined solely in the destination. The source and target administrators must coordinate the relevant cross-tenant access and automatic redemption trust settings before expanding the pilot.
The source population is important: Microsoft documents the ordinary cross-tenant synchronization of internal members, not arbitrary chaining of guest accounts from one tenant into another. Groups can be used to define which employees should be provisioned, while synchronization of group objects themselves can involve different capabilities and licensing requirements. Keep that distinction clear when designing the initial scope. A group chosen as a filter is not necessarily a group that will appear in the target tenant.
Select only the attributes genuinely required for the target experience. Display name, department or contact information may help colleagues discover the right person, but data minimization and legal requirements still apply. Attribute mappings and transformations should have an owner and a test case; do not assume every source attribute has the same meaning or is permitted in the target. A mistaken mapping can turn a technically successful sync into an inaccurate directory or expose information that should not have been shared.
Configure consent and cross-tenant policies on both sides
For same-cloud user synchronization, Microsoft currently documents a Microsoft Entra ID P1 licensing requirement for each synchronized user in the home/source tenant. Group-object synchronization and cross-cloud scenarios have additional Entra Governance or Suite requirements. The target tenant does not require a separate cross-tenant synchronization license solely for the provisioning operation, though other products or external-identity billing can have their own costs. Review Microsoft’s current licensing table before enabling a wider population rather than relying on a historic product price or an assumption that all cross-tenant features share one license.
The target tenant’s cross-tenant access settings must permit the intended inbound user synchronization. The source tenant must configure its outbound relationship and the provisioning job. Microsoft also requires automatic redemption settings on both the source/outbound and target/inbound sides for the seamless cross-tenant synchronization experience. These settings suppress an initial B2B invitation acceptance experience; they do not grant application permissions, consent to arbitrary apps or bypass the target’s security controls.
Security administrators should use least-privilege operational roles and document which person can alter the relationship, attribute mappings, synchronization scope and tenant-wide policy. Changes to cross-tenant trust affect more than a single Teams conversation. Use a restricted pilot group, record the intended settings and obtain authorization before changes. Avoid pasting real tenant identifiers, administrative credentials or access tokens into public demonstration files or a shared project portfolio.
Cross-tenant access policies can allow or block specific organizations, users or applications and control how authentication claims are treated. Conditional Access policies in the resource tenant may also affect what external users can do. A practical review of Microsoft Entra Conditional Access is useful because successful provisioning and successful sign-in are separate outcomes. An identity can exist in the target directory while still being blocked from an application for a legitimate policy reason.
Run a small synchronization pilot and inspect the results
Use two authorized nonproduction tenants or a permitted lab configuration and two synthetic employee identities. One user should be in the approved synchronization scope; the other should be outside it. Configure the target relationship and the required source settings according to current Microsoft documentation, then test connectivity and start the provisioning job. The expected result is not merely a green status icon: confirm that the correct external user appears in the intended target directory and that the excluded user does not.
Record the initial source attributes, the mappings in scope, the target representation and the provisioning log entry. A successful job can still create an identity with an incorrect department, display name or user type. Compare the resulting target fields with the authorized data contract and note any transformations. Avoid assuming that a synchronized B2B member or guest designation will create identical permissions or Teams experiences across every Microsoft 365 application; each service has its own controls and limitations.
Next, change one non-sensitive mapped attribute in the source and observe a subsequent synchronization cycle. Do not invent a fixed synchronization interval: check the actual job status, logs and product behavior. The test should establish whether the correct target field changed while unrelated fields remained intact. If nothing updates, inspect whether the user is still in scope, whether the attribute is actually mapped, and whether the provisioning service reported an error. An audit record with a timestamp is better than an unexplained screenshot.
Finally, remove the permitted user from scope through the documented process and examine the deprovisioning result. The lifecycle test should confirm how the target identity is handled and which application access is no longer available. Do not assume that removing access to one Team deletes every record, or that an Entra account change immediately removes all application-specific permissions and cached sessions. Document what the service actually did and the separate application checks still required.
Validate Teams shared channels as a separate scenario
For a shared-channel test, use B2B direct connect rather than treating synchronized account creation as the prerequisite. Microsoft documents mutual inbound and outbound trust between the participating organizations. A channel owner can then invite an eligible external participant to a shared channel, subject to Teams policies and the cross-tenant settings. Test that the participant can access the intended channel without gaining access to unrelated teams or applications. A user who is synchronized for broader B2B application access may still require a separately correct direct-connect configuration.
Teams guest collaboration has a different shape again: a conventional external B2B collaboration user may be invited into a team and switch context to the hosting tenant. External direct-connect participants see shared-channel resources under the relevant Teams experience. Access to files is also governed by the linked SharePoint and Microsoft 365 policies. Do not infer that a working chat proves secure file sharing; validate the actual document scope, labels and permissions with synthetic content.
A safe negative test is particularly valuable. Create one approved channel with a harmless document and one restricted channel not intended for external access. Verify the permitted collaborator sees the approved material but not the restricted material. Then test a file link forwarded to an unauthorized identity. This exposes overly broad sharing or policy gaps that a simple “invite succeeded” message would never reveal.
A separate external file-sharing review is useful when the collaboration goal includes documents rather than only conversation. Identity provisioning, Teams membership and file permissions are different layers. A secure design documents each layer and the party responsible for changing it.
Troubleshoot failed provisioning and access without loosening security
When an external user cannot access a resource, first classify the failure. Is the user absent from the target directory? Does provisioning report an error? Does authentication fail? Is the sign-in blocked by a cross-tenant or Conditional Access policy? Is the user authenticated but missing an application role, Teams membership or SharePoint permission? These are different failures and require different administrators. Changing tenant-wide trust as a first reaction can expose more users than it fixes.
For a provisioning problem, inspect the job’s current state, scoping rules, attribute mapping, target policy and error messages. Check the source identity’s eligibility and whether any previous target object creates a conflict. For a direct-connect shared-channel issue, inspect the two organizations’ B2B direct-connect relationship and Teams channel policies. The absence of a synchronized user in the target is not, by itself, evidence that a shared-channel trust relationship is broken.
Licensing and feature availability also require version-specific checks. Same-cloud user synchronization, cross-cloud synchronization and group-object provisioning have different documented licensing requirements. Product changes or regional constraints can matter, so confirm the current Microsoft Learn requirements instead of quoting a universal license rule from an older blog. If a feature is unavailable, identify the actual limitation and evaluate a supported alternative rather than trying to bypass organizational policy.
A recovery or rollback plan should include the source population, mapping configuration, target access decisions, owner approvals and a record of the original state. Test a safe de-scope and review the resulting account and application behavior. A target external identity being disabled or deleted does not automatically migrate or erase source files, and synchronization is not a tenant-migration plan. Successful closure means the requested collaboration works for permitted users and the denied paths stay denied.
Govern the relationship through employee changes and organizational boundaries
An organization using cross-tenant synchronization must plan for joining, moving and leaving. When an employee changes departments, their source group or entitlement may change; the target access should be reviewed for relevance. When the person leaves the organization, deprovisioning should be tested alongside downstream app permissions. A process that provisions accounts smoothly but never removes unnecessary access is not a complete identity lifecycle solution.
Assign ownership for legal and privacy review, source attributes, target permissions, provisioning logs, Teams policies and incident handling. The business should also know whether two tenants are part of one multitenant organization or represent distinct legal entities. Microsoft warns that cross-organization synchronization should be assessed for consent, data minimization and compliance; technical ability does not itself settle those questions. The correct scope is often smaller than the set of all users who could be synchronized.
The practical takeaway is that Teams is one possible consumer of cross-tenant identity capabilities, not the engine that performs directory synchronization. Use Entra cross-tenant synchronization when an approved lifecycle-managed B2B identity is needed across tenants, B2B direct connect for supported Teams shared-channel collaboration, and application-level policy for the actual resources. A small pilot should prove provisioning, attribute updates, sign-in, shared-channel boundaries and offboarding independently. That evidence-based approach produces a dependable collaboration design without confusing three different security mechanisms.