This post is written for organizations who have purchased licenses for the advanced compliance capabilities of Microsoft Purview Data Lifecycle Management/Records Management (DLM/RM) in Microsoft 365 and are now seeking guidance on where to start.
Refer to Microsoft’s official licensing guidance for these features at https://aka.ms/ComplianceSD.
In summary, I’m referring to the extra DLM/RM capabilities availed to organizations with any of the following licenses/add-ons applied to their users:
- Microsoft 365 E5/A5/G5
- Microsoft 365 E5/A5/G5/F5 Compliance and F5 Security & Compliance
- Office 365 E5/A5/G5
- Microsoft 365 E5/A5/F5/G5 Information Protection and Governance
This post answers the “Now what?” question, a common request I receive from potential customers. This demonstrates the complexity of the planning and configuration required to effectively implement the advanced DLM/RM capabilities end-to-end. It can be overwhelming to know where to start, but I’m here to help!
To be able to take advantage of the advanced capabilities in Microsoft Purview for DLM/RM, there are some preparation activities you can do and key areas to focus on before a single adaptive scope, retention label or policy is created in your production tenant. These activities span the technical, operational, and administrative and, depending on the complexity of your environment, can take a significant amount of time – the sooner you start, the better!
Although not an exhaustive list, here’s my summary of key activities to start with:
- Consider a Provisioning Process for SharePoint and Teams
- Assess your Azure Active Directory user attributes
- Assess your Azure Active Directory Microsoft 365 group attributes
- Analyze and streamline your Retention Schedule(s)
- Assess your SharePoint information architecture impacts
- Assess your SharePoint site architecture impacts
- Establish naming conventions
- Define and execute your Proof-of-Concept
- Prepare and execute a representative Pilot
Consider a Provisioning Process for SharePoint and Teams
To take advantage of some of the DLM/RM automation capabilities available to you, I strongly recommend having an automated, provisioning process in place for new SharePoint sites and Microsoft Teams. Although there are many reasons for having a provisioning process in place tangentially related to compliance and governance (naming conventions, site ownership, training, etc.), there are direct, significant benefits for DLM/RM. A few practical examples:
- Automatically start retention on files and messages for Project Microsoft Teams when the project is complete
- Automatically publish a set of country-specific retention labels to SharePoint sites provisioned for that country
Assess your Azure Active Directory user attributes
Azure Active Directory user attributes are used in Adaptive scopes to provide a scalable and automated way to include/exclude users from retention and label policies. Examples of places you may want to use an Adaptive scope for users:
- Apply a special retention label to all Executives’ emails (without having to manually keep track of who the executives are)
- Retain all regulated users’ Teams Chats for 2 years and the delete (without having to manually keep track of who the regulated users are)
- Azure AD administrators and Records Managers must work together to ensure Azure AD attributes required to identify users with unique retention requirements have been set and there is governance around it to keep it current
- Example: if the executive team will have unique retention requirements for their Teams chats or Exchange email, you must decide how to accurately identify executives by an Azure AD attribute
Assess your Azure Active Directory Microsoft 365 Group attributes
Azure Active Directory Microsoft 365 groups are used in Adaptive scopes to provide a scalable and automated way to include/exclude M365 Groups from retention and label policies. Examples of places you may want to use an Adaptive scope for M365 Groups:
- Retain all Microsoft Teams messages and files for German Teams for 5 years (without having to manually keep track of who the German Teams are)
- Retain all Channel messages for Executive Teams for 10 years (without having to manually keep track of who the Executive Teams are)
- Azure AD Administrators, developers, and Records Managers must work together to ensure Azure AD attributes required to identify M365 Groups with unique retention requirements have been set and there is governance around it to keep it current
- Example: if German teams will have unique retention requirements for their Teams messages and files compared to US teams, you must decide how to accurately identify Germany Teams by an Azure AD attribute during the provisioning process
Analyze and Streamline your Retention Schedule(s)
- Gather all retention schedules for your organization and start the consolidation, simplification, and rationalization process. If your regulation will allow for it, simpler is better for both ongoing administration as well as end-user experience.
- Take a holistic look across all retention schedules and start to determine:
- Types of retention capabilities that may be required. (For example, event-based retention, permanent retention, disposition review, adaptive scopes, etc.) Use this list to build your DLM/RM learning plan for the capabilities you may require. Ensure you also include these capabilities in your proof-of-concept and pilot
- Information architecture requirements (content types, metadata) to be able to use automation for applying a retention label to SharePoint items based on document properties. Do you have existing metadata you can leverage, or will you have to add new metadata? Are you leveraging the tenant level term store to tag content in a consistent manner across your tenant? Based on your assessment, start preparing for the change (SharePoint Information Architecture section below) and incorporate this into your provisioning process
- Site architecture requirements (how are your SharePoint sites and Microsoft Teams currently structured? Does it align with your retention schedule in any way?) (For example, do you have sites/teams provisioned for each division/department/team and is there a requirement to have department-specific retention labels published to each?) Based on your assessment, start preparing to clean them up (SharePoint Site Architecture section below) and incorporate this into your provisioning process
Assess your SharePoint Information Architecture impacts
If you want to automatically apply a retention label based on a SharePoint metadata value or a content type, the groundwork must be in place for you to do this. Organizations who already have an established, well-maintained information architecture will immediately be able to benefit from this automation capability. If not, there’s work to be done. Some tips:
- If you’re not using the tenant term store in the SharePoint admin center (~/_layouts/15/online/AdminHome.aspx#/termStoreAdminCenter) for terms that may be used as metadata across your tenant, consider using it. There are many benefits to this… it provides a central administrative spot to maintain the list of terms, provides consistency across your tenant for how things are tagged, and will also allow you to use a managed metadata column pointing to the tenant-level term set to automatically apply a retention label across all sites with an auto-apply label policy
- Use the Content Type Gallery (~/_layouts/15/online/AdminHome.aspx#/contentTypes) at the tenant level to standardize both content types and metadata across your tenant. This will also allow you to automatically apply a retention label consistently across many sites with an auto-apply label policy.
- Include these standard content types and metadata artifacts in your provisioning process
Assess your SharePoint Site Architecture impacts
If you have retention requirements that will vary depending on conditions that are settable at a SharePoint Site/Microsoft Teams level such as:
- Publish a unique set of regional retention labels to each region’s Sites and Teams
- Publish a unique set of divisional retention labels to each division’s Sites and Teams
- Automatically apply a retention label to all documents on “Completed” project sites (assuming a SharePoint site is provisioned for each Project)
… then you must be able to identify your Sites and Teams with these properties so you can use the Adaptive Scope feature. This is done by storing a value in the SharePoint site property bag. Once you know how your retention schedule will align with this structure, start working to store the properties to enable it in your provisioning solution as well as adding/updating the property on existing sites.
Establish Naming Conventions
There are several places where a naming convention will be helpful for ongoing administration. In all places, you cannot change the name after-the-fact so having a plan and choosing your names carefully before hands touch the keyboard is important. Here are some places where naming conventions are helpful, particularly in large tenants with lots of these artifacts:
- Adaptive scope names
- Retention Policy names
- Retention Label Policy names
- Retention Label names (there are disallowed characters)
- If working in a production tenant (yes, sometimes it happens), what wil be the test names for the above (e.g., prefixing all test retention labels with TEST- is a good idea)? This will allow you to identify and clean them up after-the-fact more easily
Define and execute your Proof of Concept (PoC)
A well-chosen, scenario specific PoC is highly recommended for many reasons. It will demonstrate how the Purview capabilities will solve your DLM/RM needs and will help identify any gaps that may exist. Ideally, the PoC is in a non-production tenant and will show the complete end-to-end solution. The intent is it will never go into production; its purpose is to help you understand how the features work and what impacts there may be across your organization (people, process, and technology) by using it. This is also the best way to test the records management settings you control for all SharePoint sites defined in the Records Management tab of Purview. This includes settings such as allowing deletion of labeled content, configuring record versioning, and allowing editing of record properties – all end-user impacting.
An example PoC is implementing a small, representative sample of record series from your Retention Schedule into the Purview File Plan with the capabilities you intend on using across the board and then observing the behavior. This could include features such as: adaptive scopes, retention policies, published and auto-applied retention labels, event-based retention labels, and disposition reviews.
Allow sufficient time for the PoC. To see the complete end-to-end process for many of the DLM/RM features, it can take many weeks… plan accordingly by allowing for enough time.
Prepare and execute the Pilot
Customers I’ve worked with have piloted the DLM/RM capabilities in different ways; however, the end goal is to pick a pilot that will not only trial the technology, people, and process impacts, but will also help to define a repeatable process for it where possible. Here are a few examples where I’ve seen success:
- Use a small subset of the File Plan targeting a specific team/department and make the team part of the Pilot
- Define common scenarios across your organization (1 organization I worked with had defined a set of common scenarios they thought were representative of the bulk of their content) such as approval processes, policy management, project work, etc. and select 1 or more of those scenarios for the Pilot
The Pilot will trial the capabilities with end-users with the intent that once fine-tuned, will eventually move into your production environment. In all cases, the ideal outcome of the Pilot is to build a repeatable process; however, DLM/RM is not cookie-cutter and there will be deviations. The pilot should, however, help build out end-user training, operational processes, and even policy updates to provide some level of improved consistency, governance, and ultimately compliance across your organization.
Based on your Pilot learnings, you can begin to map your complete retention schedule into the Purview File Plan following the repeatable process where you can; however, only create retention labels in DLM/RM if there will be content requiring that label. There are retention label limits, and you don’t want to bump into them.
I hope you found this list of activities helpful to start preparing for implementing DLM/RM in your tenant.
Thanks for reading.
So so so so true! Coming from a collabtech, IA, governance, and strategy background, I often focused on such critical matters, and was told a few years ago that “you’re over complicating it” and I should just focus on using the new features, which aren’t particularly useful unless applied selectively.
Clueless people aside, perhaps consider these additions to your list:
0 – Scope – Identify the part of the institution/enterprise that is in scope for the effort; enterprise-wide is way different from legal or HR or finance or a business unit. This impacts everything.
10 – Define the scaling strategy – a PoC and/or pilot can only address a small set of use cases relative to the broader entity. If the org has 10 major separate agencies/business units/whatever, a central function may provide toolkits and governance, but the BUs will need to implement specifics (and engage their customer base on the adoption front).
Back in the “SharePoint days” (late 00’s), we got really good at this b/c you we set up the top-level IA, enterprise content types, a global service, governance, extensibility toolkits, and other structures, and then provided business units with consulting services (by the internal service provider) to ensure adoption.