Table of Contents
Decision to Use Sublabels is an Implementation Issue
One of the topics that should be discussed before the implementation of sensitivity labels in a Microsoft 365 tenant before the creation and publication of labels to users is whether to use sublabels. Take the example in Figure 1 where three sensitivity labels (General, Confidential, and Highly Confidential) are parents to sets of sublabels. The General label has two sublabels (also called child labels).
A sublabel works like a primary label and can apply protection (rights management-based encryption) to email and files. It’s not When you use sublabels, the parent label acts as a container and cannot be chosen by users to label content in applications, even if it has settings to apply protection. Only the sublabels are selectable.
The Logic Behind Using Information Protection Sublabels
The main reason to use sublabels is to create a logical structure to guide users to apply the most appropriate label to content. The logic is that the parent labels are the major entry points for users to choose from. For instance, using the structure shown in Figure 1, if the user wants to label a file that’s not personal or public, they have three options to choose from. Their knowledge about the information in the file should help them to distinguish between General, Confidential, and Highly Confidential. Once they’ve made that important decision, they then decide the degree of sensitivity of the information and apply the most appropriate sublabel.
The Logic for Avoiding Information Protection Sublabels
The argument against using sublabels is that if the implementation team isn’t careful, it is easy to create a complex structure that hinders rather than helps users make the right decision. The logic is that a simple flat list of sensitivity labels ranked from least important (at the top) to the most confidential (at the bottom) is easier for people to understand.
This approach works if users are presented with a limited number of labels to choose from. Showing six labels with carefully chosen names that clearly communicate the level of confidentiality is likely easier for users to understand and navigate than a list of fifteen labels. In international deployments, the display names for sensitivity labels can be translated into different languages. In this scenario, it’s important that the label names have the same relevance in all languages.
Deployment of Information Protection Sublabels
Creating sublabels follows the same process as creating a regular label. The big difference is the starting point. To create a sublabel, you select the parent label (which logically must be created first) and then choose the option to create a sublabel (Figure 2). Part of the creation process is to determine the priority order for sublabels within the parent label’s set, but aside from that, if you can create a regular label, you’ll have no difficulties creating a sublabel.
Like regular labels, sublabels must be deployed to end users through label publishing policies. Each policy publishes a selected set of labels to target users. If a policy includes a parent label, make sure to include all its sublabels.
The Purview compliance portal doesn’t allow regular labels to become sublabels or vice versa. However, this can be done using PowerShell. To do this, you must sign into the Exchange Online management module and then connect to the compliance endpoint to retrieve details of the sensitivity labels defined in the tenant. The important information you need is the ImmutableId, the GUID that identifies a sensitivity label. Here’s how to sign into the compliance endpoint and list the current set of sensitivity labels:
Connect-IPPSSession Get-Label | Format-Table Name, ImmutableId Name ImmutableId ---- ----------- Public 2fe7f66d-096a-469e-835f-595532b63560 No Encryption 8b652c9a-a8b7-40ec-bb1a-c5334b1b7fef Non-business use a49e1277-93db-4a2f-8105-43c5196b4fef
Find the label you want to be the parent and the label you want to make into a sublabel. Then run the Set-Label cmdlet to connect the two labels using their GUIDs.
Set-Label -Identity "969ca0c8-9699-4950-a943-32c1e044b546" -ParentId "d179cfc9-43d4-41b6-9ddb-3e1aaf3224c8"
Transforming a regular sensitivity label to become a sublabel changes the priority order of the label. This can lead to priority mismatches when users apply the sublabel to files stored in SharePoint Online if container management labels are used to manage sites. It’s a small point to be aware of.
To disconnect a sublabel from a parent label, run Set-Label and set the parent label identifier to $null. These commands disconnect a sublabel and resets its priority:
Set-Label -Identity "969ca0c8-9699-4950-a943-32c1e044b546" -ParentId $null Set-Label -Identity "969ca0c8-9699-4950-a943-32c1e044b546" -Priority 30
Organizational Culture Drives the Decision
Deciding to use or avoid sublabels essentially comes down to organizational culture. Companies with a computer-literate user community might find the granular nature of sublabels easy to use where a tenant supporting less technology-oriented groups might find that a simple list of sensitivity labels is the best approach. As part of the deployment process, it’s a good test to test both approaches to see which works best.
Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.
Nice article.
We havn´t started, what scope is best to start with? Teams, Sharepoint, Exchange?
Or some other recommendation?
Sounds it´s more complicated to educate endusers and create the process compared to the technical part.
I’d start with SharePoint. Relatively fewer documents are created than email and it’s possible that more confidential information is held in documents.
Teams means container management because Teams cannot apply labels to messages.