I talk to many compliance professionals who are in the throes of reviewing their retention schedules with the intent of making it “software ready” for SharePoint Online. A common approach I see is aligning record series within the schedule to a functional business classification purpose-built for their organization. The advantage of this approach is its suitability to integrate with traditional SharePoint information architecture to help with auto-applying retention labels.
The problem is that many compliance professionals don’t have the background to be able to know how to turn those functional classifications into something you could use to apply a retention label. That’s why I decided to write this post. Even if you’re not the one who will do the configuration in your tenant, understanding the back-end setup will help when having conversations with those that will.
Customer question: “How can we turn a library’s metadata column value into something we can use to automatically apply a retention label?”
Steps to accomplish this requires knowledge of SharePoint Information Architecture, Search, and Keyword Query Language (KQL) along with the following permissions:
- SharePoint Administrator to do Search schema configuration
- SharePoint site owner to do the library changes
- Records Management role group to do the auto-apply label configuration
To demonstrate, I’ll cover 5 of the most common SharePoint information architecture artifacts and the steps you must take to automatically apply a retention label to a file for each one:
- Scenario 1: Content type
- Scenario 2: Managed metadata column
- Scenario 3: Choice column
- Scenario 4: Date Time column
- Scenario 5: Yes/No column
Detailed infographic for describing the steps for each scenario above can be found on page 8 in my Tip Sheets!
Recently rolled out is a feature to allow Records Management admins to simulate the results of an auto-apply retention label policy. This will allow admins to test the policy before deploying it in production. It will work with both Sensitive Information Types and KQL properties (what my 1-page infographic is describing).
Tip: an alternative to the simulation feature for testing your auto-apply label policy is to do it in a non-production tenant and use an auto-apply label policy targeting a single Modern Communication site. That removes the most amount of variables in your process. If you don’t have a non-production environment available to you, provision a “test” modern Communication site on your production tenant, if allowed.
Thanks for reading.