RETENTION MANAGEMENT - NAMING CONVENTIONS IN PURVIEW

#SharePoint, #Microsoft365, #Purview, #InformationDesign

Audience: Information Management Advisor, Programme managers, Solution Designer

Author: Jonathan Stuckey

Retention management is critical task for organisations aiming to comply with regulatory requirements, manage their information lifecycle, or as part of incorporating AI into everyday processes. But Retention & Disposal is boring. In fact it should be a sitter for introducing AI / Generative AI to help automate - but the tools have long way to go yet.

Retention Label Management Interface designer

If you're managing documents in M365 SharePoint and OneDrive the easiest option is leveraging Purview's native Retention Management suite.

The most challenging aspects of implementing retention controls with Purview lies in choosing the right naming conventions for retention labels and policies, and distributing them.

Why? Well lets assume you have an hour to waste, we had coffee and I bored you silly - and we settled on the fact that the conventions you choose influence not only how records managers interact with the system but also how end users understand and apply retention rules.

But why focus on Naming Conventions? Purview's Retention and Labelling UI's are appalling; they are badly laid out, the reporting and sentencing interfaces are horrendously slow when dealing with high-volumes of content, there's massive duplication and reuse without clarity on which process or roles need the minor variations... I can go on (at length) but I'll need more than coffee.

To simplify things it is better to have strong, consistent and readable naming convention for labels, policies and reports to aid the administrator navigate the morass.

This post examines three common models for naming retention labels in Purview, and how to select an approach that suits your need.

Understanding Retention Management in Purview

This article assumes you understand that retention management involves defining how long data should be kept and what happens to it at the end of its lifecycle. I'll also assume that you are interested in using Microsoft Purview to support this because your company has (probably) already bought it in the existing license-plan - and you don't get a choice.

Well Purview provides 2 main mechanisms for retention management:

• Retention Labels: Targeted rules that are applied to content to specify retention duration and disposal actions, which can be anywhere; or

  
  

• Retention Policies: Broader rules that apply a retention setting across entire services (Exchange, OneDrive, SharePoint, Teams), specific locations (sites, libraries) or content types.

  
  

While I can think of a couple of valid reasons for using Retention Policies, they lack focus, flexibility and specificity that's useful with a mixed-bag of content you find in most Microsoft Teams or SharePoint sites.

Retention Labels are the building blocks for targeted management, that supports your disposal authority and schedule. The way labels are named and structured affects how easily they can be managed, understood, and updated.

Approaches to Retention Naming Conventions

I'm sure I'll get it this time...

If we assume you don't have some random engineer just creating labels because support thinks its a good idea as part of data-security, then an organisation would typically adopt one of the following approaches for naming when creating retention labels in Purview:

1. One-to-One Mapping to R&D Schedule (Rule Name Reference)

Examples: these have had to be seriously manipulated / truncated to meet constraints

Label	Notes
6-1.1.1  Policy & Planning - Policies & Procedures - Organisation	GDA 6 class, name shortened
6-2.1.3 Ministerial Parliamentary Legal - Records - Correspondence	GDA 6 class, name shortened, reworded
6-3.1.1 HR - Personnel Files - CEO and Tier2 manager	GDA 6 class, shortened, reworded
7-1.9.0 Administrative - system temp files - non-user generated	GDA 7 class, name

This model creates a retention label for every individual rule in your Records and Disposal (R&D) schedule. Each label name directly references the corresponding rule, and can only be applied if you've setup your Sites and Libraries like a classic Fileplan from the year-dot. Ultimately this approach is IM heavy, needs lots of advisors applying and managing the labelling and needs lots of end-user support.

Characteristics	Labels mirror the R&D schedule exactly. Each label corresponds to a specific rule name. Results in a large number of labels, often hundreds.
Advantages	Clear traceability between labels and R&D rules. Easy for records managers to audit and verify compliance. Simplifies updates when R&D rules change
Disadvantages	Overwhelms end users with too many labels, and rigid content structure. Difficult for non-specialists to understand label purpose. Significant implementation and ongoing administrative overhead.

2. Mapping by Disposal Action Reference

Examples: based on acronym and period reference for action

Label	Meaning	Notes
A15L Retain for 15 years	Archive	No class reference. Inferred activity. No context
D03M Retain for 3 years	Destroy	No class reference. Inferred activity. No context
RETAIN Retain forever	Keep	No class reference. Inferred activity. No context
T10M Retain for 10 years	Transfer	No class reference. Inferred activity. No context

This approach groups retention labels by disposal action, combining retention term and trigger into fewer labels. It's a Records action focused specialist approach, and assumes the end-user is not really involved. Often tied to specialist vendor tools/add-ons. Assumes scalable workflow, and highly-trained records manager/advisor on hand to take responsibility. Often requires strong, scalable workflow to manage volumes.

Characteristics	Label name codifies disposal actions rather than individual rules. Labels are technical and records manager-focused. Typically cam get away with running fewer than 50 labels*
Advantages	Easier to manage for Records Manager due to smaller label set. Suitable for trained specialists who understand disposal actions. Reduces label clutter in the system UI filters, but not volumes.
Disadvantages	Labels are not user-friendly** or descriptive for end users. Difficult for users to select correct labels without training. Limits flexibility for future updates or rule changes.

*working on the assumption that have the number of labels created are: ((no of actions) x (qty duration periods)) where 4 x basic actions, and 11 standard potential terms; i.e. potential total of 44 labels.

**assuming using classic nomenclature of ['initial'period] (e.g. D3 = Destroy in 3 yrs from trigger)

3. End-User Readable Consolidated Labels

Example: aggregated similar content, context or associated labels with common actions

Label	Notes
Governance - Board and Commission - records management	DA rule wording represents like rules.
Health and Safety - Contact Tracing - records	GDA 6 class in other field; reworded, represents like rules
Business Information Systems - Commissioning - systems	GDA 6 class separate admin field; reworded, represents like rules
Admin and Transitory - record copies or migrated system content	GDA 7 class separate admin field; reworded, represents like rules

This option consolidates similar or related R&D rules into user-friendly labels that make sense to end users, as well as mapping back to the DA for the Records manager reporting. It's a hybrid approach that assumes the end-user will be involved and labels should be human-readable. Balancing increased no. of labels with delegated ownership. Heavier on mapping work, but easier on end-user training and change-of-sme.

Characteristics	Labels are descriptive and easier to understand. Combines multiple R&D rules into fewer labels than model 1. Larger label set than model 2 but smaller than model 1* (10s, not x00s)
Advantages	Improves end-user adoption and correct label application. Balances usability with records management needs. Supports easier communication and training.
Disadvantages	Requires careful design to avoid ambiguity. May complicate traceability back to specific R&D rules.

And a (Global) Retention Policy?

Lets not cover it and say we did. This article is not about use of Retention Policy in Purview, because: they lack management granularity and flexibility; are too difficult to apply different rules to different content in same area, and there is no reporting clarity or control for users.

Naming Conventions Affect Multiple Aspects of Management

Retention labels are collected together in Label policies for distribution to specific sites, groups etc, but they can also be applied via Automation through use of sensitive information types and trainable classifiers. So, the naming convention chosen impacts service setup, admin, maintenance and reporting across:

• Policy Creation: Labels with clear, consistent names make it easier for identification and selection when creating and maintaining policies.

• Auto-labelling: Sensitive Information Types can be used to drive automation of retention labelling; Clarity on naming to avoid misclassification and incorrect retention is vital to ensure clean information governance (at scale)

• Scalability: Because Purview tools don't support versioning and history of changes to labels, policies, workflow or audit monitoring Naming conventions must be used to help support identification of updates for adding, editing or retiring labels/policies

• User Training: Clear, descriptive labels reduce training time and errors in label application; simplifying creation of guidance and support-content.

  
  

Choosing the Best Model for Your Organisation

The best naming conventions focus on support for who will primarily use the system, and the organisation’s priorities. Making the rules so obvious that a toddler (or executive) could follow them is good practice. With Retention and Disposition though, most people don't care enough to want to be involved but will "scream the house-down" if there content is archived/lost/destroyed and they weren't consulted.

The way to assess which approach you use, comes down to: Culture, Education (IM lifecycle), Regulation, Reporting, Ownership, and (ultimately) Accountability for the smooth operation of Disposal.

Model	Best For	Considerations
One-to-One Mapping	Needing detailed control and traceability	Large label volume; complex for users
Disposal Action Mapping	Focused on disposal actions	Smaller label set; poor user usability
End-User Readable Consolidation	Prioritising user adoption and clarity	Balanced label count; requires design effort

Which way to go?

Easy - for a public sector / regulated organisation use one-to-one labels! (option 1)

You would think that a government agency with strict compliance requirements may prefer the one-to-one mapping model to ensure every R&D rule is represented and auditable.

I hear retirement calling

Um, no. In fact, most organisations (public sector or otherwise), want to keep-it-simple. No one wants lots of manual labelling or overly complex documentation, traceability or reporting.

The fact is that virtually no organisation has used a fixed fileplan model in decades, and the more we move to high-volume creation and generative AI the less likely we are use them.

In addition to this there is a decreasing availability of people with RM/Information Management skills and experience available in the workforce.

If your information / records manager leaves, will the next person have the skill and patience to pick-up handling '00s of labels and actions?

So, go with the DA Reference labels? (option 2)

Well... maybe. This comes down to who's responsible and accountable for running things. When organisations thought they could dump the responsibility for managing content on a Records Manager - we were happy to have obscure, archaic conventions - because it was an SEP ('somebody else's problem').

Applying disposition to labelled items

Given a lot of Disposal is about relatively easy actions, it seems this approach would do what you need (Archive, Transfer, Destroy etc) - but actually its not the action, its the review and decision process you need and that's usually tied to the Business rules and process (context) for the content (document) and experience to navigate the seemingly infinitely variable options on when/why/how to Dispose (Burn)

If you've an old-school Record Manager, they'll understand what you have - but a lot of them are reaching the end of their working life, so do you think succession planning will cover IM roles, or are you hoping 'AI' will rescue you?

Record & information managers are not hoarders - they are quite happy to 'burn it' when stuff should not be kept any longer ...but only the items which rules identify!

What? So, we should use Consolidated labelling then? (option 3)

Hmmmm, Well - yeah, but, no but.

About to deliver some user training

Things have moved for users and Information Managers alike. Everyone has 'self-service' and 'personal productivity' tools; stuff has become increasingly regularly lost (in silo's). Unfortunately, most people do not think like "Records Managers"; we don't use consistent file-plans, or diligently look for the right label to add.

Human readable labels, which link to specific types of content and information (as per Disposal Schedule) help users make decisions but its not about label its about the content and the context.

Scanning through 60 - 80 labels, where names provide context helps with maintenance, processing and reporting on progress (or lack of). Peeling through 200+ labels to assess the same thing is a lot harder when users don't follow filing rules. Labels that help group via context are key when needing users to be responsible and accountable. Its all about education.

Opinion: names which give context help in identifying who to talk to when things are not in the right-place, or need decisions on deferring vs. destroying.

Designing for Scalability and Transferability

Retention management with Purview is not a one-time setup. Organisations have to plan for:

• Updates to R&D schedules: New rules, changes in retention periods, or disposal actions, changes to collections and corpus scope (new sites, retired sites...)

• Tool Integration: Naming conventions should be consistent across Purview for retention labels, policies etc.

• Automation: Consistent naming supports automated label application, processing actions and reporting.

• User Turnover: Clear labels help new staff understand retention requirements quickly.

  
  

A naming convention that is too granular, too obscure or too vague will hinder these goals.

Recommendations for Implementation

I'm not going to tell you "you must choose!" one option. This comes down to what is appropriate for your organisation, and (today) people like me can still help you with this.

What I will recommend for implementing Purview Retention Labelling is:

• Know your audience. Be very clear and document who will use these labels.

• Engage both records managers and end users when designing labels to balance technical accuracy and usability.

• Know your system constraints so your convention doesn't fall over name-lengths (64Chars), or special character restrictions etc

• Use consistent prefixes or suffixes for business terms, function names etc - remember to keep them succinct (see system constraints)

• Avoid unnecessary or superfluous verbiage - avoid retention periods, disposal actions etc - they are already captured and displayed to user with the tooltip

• Document label naming conventions and maintain a glossary linking labels to R&D rules.

• Pilot the naming convention with a subset of users to gather feedback before full deployment.

• Create comprehensive set of examples to support user, and SME training and support

• Review and update labels regularly to reflect changes in retention requirements.

  
  

Summary

Good practice is have clear, understandable and human readable labels (just don't include the retention-period in the label name!) - you will almost certainly have people who don't understand 'short-codes' supporting reporting, or updates during lifecycle of your deployment.

Be led by business owner, and your IM Advisor (if you are lucky enough to have one), and make sure you test the actions because some of these System Actions do not equate to classic Disposition Schedule actions.

Want to know how to do this on Purview, quickly, effectively and actually start processing your information (and getting rid of the expired rubbish)? Give me a call.

About the author: Jonathan Stuckey 

Reference

Microsoft | Purview: Learn about retention policies and labels

Microsoft | Purview: manage retention labels with a fileplan

Microsoft | Purview: security and compliance protections for generative AI apps

Microsoft Roadmap: Filtered on Purview in development

Disclaimer

Generative AI was used in the creation of this article to provide: images, structure, and review content for consistency. Article copy was created by author, and reviewed inline with personal views and experiences. 3rd party content referenced is solely responsibility of the original owner. Any errors or issues with the content in this article are entirely the authors responsibility.