Identity administration · Sources checked November 7, 2026
Microsoft Entra administrators with several tenants have a new provisioning option to assess. The useful question is which team will control access after a group appears in another tenant. A successful synchronization job should be the start of that review, not its conclusion.
What the November preview adds
Microsoft’s multitenant documentation changelog, updated November 4, lists a November 2026 preview for creating role-assignable groups across tenants in the same cloud. It does not synchronize the source group’s role assignments. The entry gives a month, not an exact release day or a general-availability commitment.
For an organization with central identity operations and separate business-unit tenants, that distinction matters. Decide who approves membership and who authorizes a role in each destination. Matching names across directories are not sufficient evidence that the same access was intended.
Check eligibility before building a pilot
The synchronization overview requires Entra ID Governance or Entra Suite for every synchronized user in the source when groups and members are synchronized. P1 covers user-only synchronization, including groups used merely to select users. Target synchronization itself needs no license, but target features can. Group sync does not cross Microsoft clouds or support nesting; scope must be assigned users and groups. The cloud table supports groups within Commercial or within Government, not within 21Vianet.
Separately, Microsoft’s role-group guidance requires P1 for that feature and P2 for PIM just-in-time activation. Role-assignable groups use Assigned membership, not dynamic membership, and a tenant can have at most 500. Their role-assignability cannot be changed after creation. Check these feature requirements alongside the synchronization entitlement rather than treating one license line as permission for everything.
The order of configuration matters
The configuration guide requires both inbound group-sync permissions in the target. Enable group provisioning and save a direct isAssignableToRole-to-isAssignableToRole mapping, applied only on creation, before adding the source role-assignable groups to scope. Leave its default blank and matching unchecked; use neither a constant nor an expression. Existing non-role-assignable target groups are not converted. Microsoft’s replacement procedure requires destructive hard deletion of the old target groups, planned with their administrator; do not delete source groups.
Treat an existing deployment as a migration review. Make a dependency inventory before considering replacement: which applications, access reviews, automation and operational procedures refer to the affected group? Give each dependency an owner and an acceptance check. A production deletion is a poor way to discover an undocumented dependency.
A practical acceptance record
Use an approved test environment and disposable identities. Write expected results before making changes, and keep a reviewer separate from the person executing the pilot. The following is our suggested test plan, not a claim that we ran a tenant deployment:
- Identify objects precisely. Record the source and destination tenant and group identifiers. Separate newly created test groups from groups that already existed. Avoid relying on display names, especially when several teams use similar naming conventions.
- Separate creation from authorization. Check the resulting object and membership first. Record the intended destination role, its approver and the business reason separately. Do not broaden roles merely to make a failing test pass.
- Test allowed and refused work. With a dedicated test member, exercise one harmless operation the approved role should permit and one it should not. Record observable results. A green provisioning indicator cannot replace an access test.
- Test the exit path. Agree how the pilot’s access will be withdrawn, then verify the result with the same test identity. Measure the observed timing rather than promising immediate revocation. Record unresolved sessions or other access paths for investigation.
Before expanding, have both tenant owners sign off on the objects, membership authority, approved destination roles, test evidence and rollback plan. If replacement is involved, keep it in a separately approved change. We reviewed public documentation, not a live Entra configuration. Availability and behavior in your tenant still need verification.