Two groups overlap when their memberships are nearly identical, usually because teams created parallel groups for the same population. Overlap creates redundant access paths, doubles maintenance, and makes every membership question ambiguous: which of the twins is the real one?
Where twins come from#
A department gets one group from IT, another from a project, a third from a migration, and each accretes grants over time. Nobody merges them because nobody can prove the memberships match closely enough to be safe, so the twins persist and drift.
Measuring overlap manually#
Overlap between two groups is set arithmetic over transitive members: the size of the intersection relative to the smaller group. Manually, export both transitive member lists and compare:
Connect-MgGraph -Scopes "Group.Read.All"
$a = (Get-MgGroupTransitiveMember -GroupId <id-a>).Id
$b = (Get-MgGroupTransitiveMember -GroupId <id-b>).Id
$shared = ($a | Where-Object { $b -contains $_ }).Count
"Overlap: $shared of $([Math]::Min($a.Count,$b.Count))"From measurement to merge#
Pairwise checks work when you already suspect two groups. Finding overlap across a whole tenant means comparing every pair, which is quadratic and impractical by hand. And once found, a merge needs the same care as any restructure: what does each twin grant that the other does not?
VisualizerEngine
How VisualizerEngine does it
Overlap detection runs across the tenant and surfaces groups whose memberships almost entirely overlap, ranked. The hierarchy shows what each twin grants, and what-if simulation previews the merge, listing everyone whose access would change before any group is touched.