Superseded or Obsolete Retention in Microsoft 365 | Basic using E5

Reading Time: 9 minutes

If you’re in the Records Management space, you’ll be familiar with the idea of retaining something for a period of time once it is deemed superseded or obsolete.

If you’re NOT in the Records Management space (IT for example) and you’ve been given the task of implementing this (common) retention requirement using the Microsoft 365 retention feature-set, this post is for you! You need to ensure the organization is compliant with this regulation while continuing to allow collaboration and ongoing changes to the content. Seems like a tall order, let’s dig in…

I’ll start by defining what superseded or obsolete means using a corporate policy example.

Superseded: corporate policy undergoing major/minor revisions with the scope and intent of the policy remaining the same. Changes are made to a new version and the previous version is considered superseded.

Obsolete: a corporate policy is no longer appropriate for the purpose it was created for. There may be a new corporate policy with a different name/number that will potentially reference the obsolete policy as its predecessor.

Based on numerous conversations I’ve had with Microsoft 365 customers, I know many do not have the benefit of being able to leverage E5 Compliance features when implementing retention and records management controls. (Reference: Information Governance Licensing Guidance) I also know many customers have chosen to stay with native Microsoft 365 Information Governance capabilities rather than purchasing additional third-party products to meet their requirements. I’m here to help.

Because of this desire, I’ve designed 4 methods to accomplish the Superseded or Obsolete (S/O) retention requirement using strictly Microsoft 365 Information Governance capabilities to help out my customers:

Are these designs the only way of accomplishing the S/O requirement? No. As with most things SharePoint and retention, there are several ways to get things done. These 4 designs are a result of thoughtful consideration of the retention requirements, ongoing maintenance, and minimizing technical debt.

The design chosen will depend on the license available to you and whether you need Basic or Advanced (my terms, not Microsoft’s). The key difference between the two…

Basic includes the storage of S/O retained content in native Office format.

Advanced includes the storage of S/O retained content in a long-term archival format such as PDF-A, rather than in native Office document format. **As of the time of this writing, you will need to utilize a (paid) connector within Power Automate to convert from Office to an archival format such as PDF-A.

A variant of all designs is to provide the ability to easily go back in time to see any official policy as of an effective date, often a requirement from a regulatory perspective. Although Version History can be used for this purpose, sometimes a separate instance of the superseded/obsolete policy is required/preferred. This is covered in my Advanced designs as well as Basic E3.

---

Basic Superseded or Obsolete using E5 Features

Retention requirement: “Retain all Corporate Policies for 7 years once superseded or obsolete.”

Note: this post assumes corporate policies under retention are NOT a regulatory record, instead they are simply a record. This is because a record label will allow for versioning, something required for the S/O retention requirement I’m building in this post, whereas a regulatory record label does not allow for versioning. Please check out my Microsoft Sway for a table of the retention label differences: Retention Label Differences.

Below is a high-level Visio diagram of this design. It includes 2 document libraries:

• WIP Policies: this is the Work-In-Progress library where policy authors add new policies and make revisions to existing policies. Policy viewers across the organization do not have access to this library. Key columns for this retention solution are Policy Status (Active, Obsolete), Copy Status (Pending, Copied), and Effective date.
• Approved Policies: this is where the approved, effective, policies are stored. Policy viewers will have read access to this library. Approved Policy content will typically be surfaced on an intranet or a Corporate Policy Centre leveraging Microsoft Search.

At the heart of implementing the necessary technical controls for a Superseded or Obsolete retention requirement using E5 Compliance is a record label and its versioning.

---

Step 1: Create the record retention label to start the retention period based on when items were last modified and either delete automatically or optionally trigger a disposition review. Publish the retention label to the Corporate Policy Centre (SharePoint Communication site where the WIP Policies library lives).

---

Step 2: The WIP Policies library will have the record retention label set as default so all new policies added will automatically have it applied.

What does the end-user see that’s different? In this example, the default record retention label name is Corp Policy so each document added/uploaded to WIP Policies will have that retention label applied. A lock icon will display beside the policy name and the built-in Item is a Record column will be populated as Yes. 

Note: as you can see above, there will often be additional metadata on the policies. Metadata is an important part of intelligently displaying content and to filter policies for end-users when viewing (E.g. Audience, Department, Category, etc.). Since these are typically not relevant to the retention design (unless they dictate different retention requirements), I’m not including mention of them in this post.

End-users will also see a new Record status property in each document’s detail property pane.

---

Step 3: Before any changes are made to the new policies, let’s look at a few things… I’ve left the default versioning settings at the library level allowing for up to 500 major versions (in a production scenario, you will want to increase this – the maximum is 50,000).

Before any changes are made, the policy is at major version 1.0

Making changes to the policy

If the document is Locked, you won’t be able to make any changes when you open it, although you will be able to edit its metadata. With at least Contribute permission to the document, an end-user can toggle the Record status from Locked to Unlocked to edit the content of the document:

 

Immediately upon unlocking the record (document), the visual lock icon is removed from the library view and the latest version of the document is copied to the Records folder in the Preservation Hold library (PHL). The document’s version history will be updated to show a new major version with the word Record in the Comments column. The original document is a new version that can be edited, but not deleted. The document library column Item is a Record still shows the Yes value because the document is still a record, even if it can now be edited.

The document version added to the PHL is considered a superseded version in this retention implementation and will equate to every major version identified as a “Record” in the document’s version history.

At this point, regular document co-authoring can occur while the policy document is unlocked with updates creating new major versions. You may want to consider adjusting the versioning settings for your library with these possible changes to suit: increase the # major versions, require check-out to limit co-authoring and control the major versions created, require major/minor, and/or introduce an approval process into your policy authoring process (Step 4).

As subsequent changes are made to the unlocked document, the major version will increase, however nothing will be added to the PHL. When the document changes are complete, the document can be locked again.

The next time changes need to be made to the policy, the locked document must be unlocked and the unlocked document (superseded policy) will be added to the PHL. This toggle allows for ongoing document content revisions by toggling from Locked to Unlocked throughout the policy’s lifecycle.

---

Step 4: It’s common to inject a workflow approval process for approving policy changes. When policy authors have completed their policy revisions, the policy must be approved by a Policy Administrator. It’s often important to retain this approval information as metadata on the document: ApprovedBy, ApprovedOn, ApprovalComments. Once approved, update the Copy Status to ‘Pending’.

Create a Power Automate Flow to run daily and pick up all approved, active, effective policies that haven’t been copied (Copy Status is ‘Pending’) and overwrite the previous one, if it existed, in the Approved Policies library. If it didn’t exist, store the new policy!

Important: we want to allow policy authors to do policy revisions in the WIP Policies library in advance and provide a future-dated effective date for the policy. We also only want 1 copy of the policy in the Approved Policies library. Due to this, we only want to copy/overwrite it in the Approved Policies library when the effective date is today. You can also optionally convert the policy to PDF if required as many organizations I work with prefer to display policies in PDF format.

---

Superseded or Obsolete Retention starts

How does retention work for Superseded Policies?

Items stored in the PHL are treated independently of each other because the Corp Policy retention label is configured to retain for 7 years past the last modified date. This means each item in the PHL will be retained for 7 years past the date/time they were superseded (i.e. the date/time added to the PHL). They will then go thru a disposition review process prior to permanent deletion.

---

How does retention work for Obsolete Policies?

There’s a few key things to consider for Obsolete policies. First and foremost, how will you know a policy is obsolete? This takes human judgement to make the determination. Secondly, policies can become obsolete at any time creating a situation where you could have obsolete policies being displayed to policy viewers, likely something you don’t want.

I think a regular review of Corporate Policies is a great governance process for many reasons, however it is particularly important for detecting Obsolete policies.

To help with this, my recommendation is to do these 3 things:

Thing 1: Leverage the Policy status on WIP Policies to help (values: Active, Obsolete)

If Policy Authors are aware a Policy is Obsolete, they can update the Policy status to Obsolete at any time. The “Thing 3” Flow below will ensure this same change is reflected in the Approved Policies library. To catch the policies that no one is aware are obsolete, inject a periodic review process… Thing 2. 🙂

Thing 2: “Periodic Policy review” Power Automate Flow

On a cadence your organization is comfortable with (quarterly, semi-annually, or annually), find all Active policies in WIP Policies that haven’t changed within the past period. Notify Policy Reviewers to review them, update them as required, and determine if any policies are obsolete. For each obsolete policy, Policy Reviewer will change the Policy status to Obsolete. All policies reviewed will have the Last Verified Date property updated.

Note: you are NOT required to unlock the policy to change the Policy status to Obsolete. This will update the Last modified date on the policy and the retention clock will start… Exactly what we want for an Obsolete policy!

Thing 3: “Obsolete Approved Policies” Power Automate Flow

Triggered when the Policy status changes from Active to Obsolete in the WIP Policies library. There’s a couple of ways to manage obsolete policies in the Approved Policies library depending on your organization’s needs:

• Keep them in the Approved Policies library and update the status to Obsolete. Use this as a filter to exclude them when displaying Active policies to Policy viewers thru Search
• Delete them from the Approved Policies library

Disposition Review is the last line of defense on superseded and obsolete policies. A disposition reviewer will make the final determination to either extend the retention, apply another label, or permanently delete the policy document.

---

Protecting policies you haven’t changed in 7 years that aren’t obsolete

What happens if you haven’t updated a policy in the past 7 years yet its still active? The “Periodic Policy Review” workflow (Thing 2 above) will expose these policies and they will have to go thru the review process.  Since any kind of edit on the document content or its metadata will update the last modified date for a document (and reset the retention clock), the review process will update the “Last verified date” property thereby keeping the policy Active.

---

Closing thoughts

As demonstrated by the detail in this post, implementing retention isn’t always easy. It can take hours of planning and thoughtful consideration of the requirements and how best to implement them with the features available. This is where compliance meets the modern workplace head-on and a place I spend a lot of time in.

My advice is to work closely with the Information Governance and Records Management teams in your organization to ensure you understand the retention requirements you need to implement and then dig in!

Thanks for reading.

-JCK