Microsoft is replacing the old parent/sublabel model with Label Groups, a cleaner way to organize labels without changing protection. Here’s what changes, what stays the same, and the steps to migrate safely.
Microsoft is rolling out a modern label scheme that replaces the old “parent label + sublabel” hierarchy with label groups. This change simplifies how labels are organized without changing how protection actually works on your data. If you’ve built policies, automations, and training around sensitivity labels, now’s the time to prep. (Microsoft Learn)
Understanding the Basics
What Are Sensitivity Labels?
Sensitivity labels are the workhorses that classify and protect data. A sensitivity label can:
- Encrypt content
- Apply headers, footers, or watermarks
- Drive auto-labeling
- Control sharing defaults
- Protect Teams/Groups/Sites containers
- Extend across Power BI, Fabric, and even Purview Data Map
Importantly, labels stay with the content as clear-text metadata and are published to specific users via policies. (Microsoft Learn, Microsoft Support)
What Are Label Groups?
Label groups act as folders that organize related labels into a two-tier experience (similar to the old parent + sublabel structure).
- They don’t carry protection settings—only name, description, color, and priority.
- You can’t publish a label group itself; only the labels inside are published.
- The end-user experience looks similar, but the admin model is simpler.
What’s Changing in Microsoft Purview
From Parent Labels to Label Groups
The old parent labels are being replaced by label groups in the Microsoft Purview portal. This reduces configuration complexity while preserving the two-step selection experience for users (e.g., “Confidential → All Employees”). (Microsoft Learn)
How Migration Works
- The migration is one-way and is rolling out in preview.
- If a parent label was “applicable” (had encryption, unique scope, or its own policy), Microsoft creates a new sublabel with the same name.
- That new sublabel inherits the parent’s GUID, while the new label group gets a new GUID. This preserves downstream integrations that rely on GUIDs.
What End Users Will See
- The picker still shows a familiar two-tier experience.
- Priority ordering and default sublabels remain intact.
- Justification prompts still apply when lowering sensitivity—but not between sublabels in the same group.
Sensitivity Labels vs. Label Groups: Key Differences
| Area | Sensitivity labels | Label groups |
| Purpose | Classify + protect data and containers | Organize related labels for a cleaner two-tier experience |
| Settings | Encryption, content marking, auto-labeling, container controls, etc. | Name, description, color, priority (no protection settings) |
| Publication | Published to users via label policies | Not publishable; only the labels inside are published |
| User experience | Users pick a single label (often as “Group \ Label”) | Provides the grouping users browse through access |
| GUID / references | Critical for automations and advanced settings | New GUID for the group; applicable parent’s GUID can live on in the migrated sublabel |
Source: Microsoft Learn documentation on sensitivity labels and label group migration. (Microsoft Learn)
Why Label Groups Matter
Governance and Admin Clarity
Label groups standardize your top-level taxonomy (e.g., Public / General / Confidential / Highly Confidential) while keeping precise, action-bearing labels underneath. This reduces admin mistakes and training overhead.
Reliability for Scripts and Integrations
Since Microsoft preserves applicable parent GUIDs during migration, existing automations and scripts don’t break. Still, you should validate that scripts reference GUIDs, not just label names.
Consistent End-User Experience
Users will continue to see a clean two-tier selection experience. Priority ordering, default sublabels, and container protections remain consistent.
Readiness Checklist
Inventory Your Current Labels
Export labels and identify parent labels with actions, scope differences, or unique publishing policies. These will become “applicable parents.”
Design a Simple Group Taxonomy
Keep the structure lean and business-meaningful.
Example: top-level sensitivity levels, with functional or audience-based labels beneath.
Handle Applicable Parents Carefully
If you don’t want Microsoft’s auto-created sublabels visible after migration, plan to unpublish them using Microsoft’s sample PowerShell.
Test in a Non-Production Tenant
Use the Purview preview banner to test migration, resolve name conflicts, and download a CSV snapshot before committing.
Validate Policies and Scopes
Confirm that scopes and publishing policies still target the correct users.
Re-Run Critical Scenarios
Check auto-labeling, container protections, sharing defaults, Power BI/Fabric label visibility, and Copilot interactions.
Common Pitfalls to Avoid
Publishing Groups Instead of Labels
Remember: you still publish labels, not groups.
Migrating Too Quickly
The process is irreversible. Validate everything, especially GUID-dependent automations.
Over-Engineering Label Groups
Keep the top tier simple and long-term. If you need action variations, maintain them as sublabels under a minimal number of groups.
The Bottom Line
Sensitivity labels remain the enforcement engine for Microsoft 365 data security. Label groups make it easier to organize and present those labels without changing protection semantics.
Action Items:
- Inventory existing labels
- Design a lean taxonomy
- Test migration in non-prod
- Validate policies and GUID-based integrations
With preparation, the shift to label groups can simplify your governance model while preserving protection and user experience.
Ready for Label Groups?
Simplify and secure your Microsoft 365 environment with eGroup’s expertise in sensitivity label strategy, data governance, and Purview deployment. Our team helps you design a taxonomy that works for your business, validate migration impacts, and ensure your integrations and automations keep running smoothly.