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 7 in my Tip Sheets!
Link: My DLM and RM Tip Sheets (go to page 7)
In preview now (Roadmap feature Id 109569), there 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: until the simulation feature is rolled out, you must test your auto-apply label policy. When testing your setup (and you should), I recommend doing this in a non-production tenant and using 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, provision a “test” modern Communication site on your production tenant, if allowed.
Thanks for reading.
Hi Joanne – that link doesn’t resolve for me (can’t get to this page…).
Hmmmm… I just tested it again with an anonymous account and it worked. I’ll ask on Twitter 🙂
Others can get to it. I think the link to the PDF is good – https://joannecklein.com/DLMRMTipSheets