Site icon Office 365 for IT Pros

Modernizing Sensitivity Label Grouping for App Display

Sensitivity Labels Groups
Advertisements

The End of Parent-Child Label Relationships

Message center notification MC1111778 (last updated 24 September 2025, Microsoft 365 roadmap item 386900) announces the modernization of sensitivity label grouping to a “dynamic architecture” consisting of labels and label grouping rather than parent and child labels. The new architecture supports moving sensitivity labels between groups “without losing referential integrity.” In other words, the settings of sensitivity labels remain intact when they are moved from one label group to another.

Removing the Last Vestiges of AIP

When Microsoft launched Azure Information Protection (AIP) labels in 2016, they adopted a two-tier parent-child model for organizing the display of labels. In this model, the parent label functions as a navigation location for child labels and cannot be applied to files. When sensitivity labels took over from AIP labels, the same arrangement was kept. In Figure 1, the Secret label is the parent and the All Company and My Team are child labels.

Figure 1: The Parent-Child display arrangement for sensitivity labels

When details of an assigned label are viewed in client user interfaces, the structure is displayed as Parent\Child (Figure 2).

Figure 2: Parent and child label structure as displayed in Word

The problem with the parent-child structure is its strict nature. Once a child label is created and deployed in active use, it becomes very difficult (if not practically impossible) to change the labeling structure to reflect current business requirements. The inflexible nature of the parent-child structure is the main reason why I never recommended its use to customers. It’s difficult enough to construct a workable labeling structure for a tenant without having to deal with inflexible groupings.

Public Preview and Migration

Microsoft is currently deploying the modern label architecture in public preview with the aim of attaining general availability in December 2025. New tenants created after 1 October 2025 must use the new architecture. No administrator action is required before general availability occurs, but it might be a good idea afterwards to review the current label structure to see if sensitivity labels can be presented in more effective manner to end users.

When a tenant is upgraded, any existing parent-child groups are migrated to the new architecture. During the preview, if a tenant has parent-child label groups, they can use the manual migration method invoked from the Information Protection section of the Purview portal (Figure 3). Migration is an irreversible process, so take the time to read up before plunging ahead and migrate a set of sensitivity labels in a test tenant first.

Figure 3: An invitation to launch a manual migration to the modern label architecture

Launching the migration is preceded by notification of what the expected outcome will be (Figure 4). My tenant has used sensitivity labels since their AIP predecessors and has accumulated many different sensitivity labels used for content protection and container management over the years, including two parent-child groups (for testing only).

Figure 4: Expected outcome for the label migration process

The migration took just a few seconds and only difference seen afterwards is that the parent labels are now label groups and the child labels are members of those groups. The Secret parent viewed earlier became a label group and also a standalone sensitivity label. The standalone label takes the name, GUID, and settings as the original parent label. Following the migration, I updated the display name of the affected labels and label groups to make their function obvious.

The new architecture exposes options in the Purview portal to move sensitivity labels into and out of groups. This is the big advantage of the change as administrators can now easily construct and change label groups according to business demands. For instance, I created a label group called Email Labels to organize the sensitivity labels most appopriately used for email to give additional guidance to end users. Figure 5 shows how the new label group appears in OWA.

Figure 5: The effect of adding a new label group to display labels of a certain type

Notice how all the sensitivity labels in the Email Labels group have the same label color. This might affect the carefully-crafted custom colors you might have assigned to sensitivity labels in the past. Another important change is that the standalone labels moved into the label group have priority orders based on the priority assigned to the label group. Label priority is supposed to indicate the degree of confidentiality or sensitivity of files that labels are applied to, so some rearrangement of labels is probably needed here. A change in label priority can lead to an increase in document mismatch notifications, and that’s not a good thing.

Although you can move container management labels into label groups there’s no point in doing so. First, organizations tend to have relatively few container management labels, so there’s no need for grouping. Second, the applications that use container management labels, like Teams and SharePoint Online, display container management labels in a simple list.

PowerShell Changes

A set of cmdlets in the security and compliance module support sensitivity labels. The label settings manipulated by the cmdlets use the same properties to update label group membership as was used to associate a child label with a parent label. For instance, a label group has the isParent and isLabelGroup settings set to true:

$Label = Get-Label -Identity 'Email Labels'

$Label.Settings
[isparent, True]
[islabelgroup, True]

A sensitivity label in a label group has the isParent property set to false and the identifier for the label group in its ParentId property:

$Label = Get-Label -Identity '1b070e6f-4b3c-4534-95c4-08335a5ca610'

$Label.Settings
[contenttype, File, Email]
[isparent, False]
[parentid, 62acd157-1757-4361-9a53-71ea316279ca]

To move a label into a label group, run the Set-Label cmdlet and update the ParentId parameter with the identifier for the label group. Here’s an example of moving a label into the Email Labels group:

Set-Label -Identity 'Employee Confidential' -ParentId (Get-Label -Identity 'Email Labels').ImmutableId

To move a sensitivity label out of a label group, pass $null or the identifier for another label group as the parent identifier.

Heading to a New Architecture

Referring to a new way to manage sensitivity labels for display in applications as a new architecture is a stretch. However, it’s still a good change. It will take time for tenants to figure out how to best use label groups, but that will come in time. In the meantime, the task is to migrate to the new architecture, either manually or by waiting just a few more weeks.


Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Exit mobile version