As a Compliance consultant focused on Information Governance and Records Management, I’ve had the good fortune of seeing quite a few retention schedules from customers over the past few years. A common retention requirement I see across them is based on a calendar year (CY).
Examples from a recent customer:
At first glance, you may think the created date could be used as the starting point for calendar year retention (approach 1 below); however, this may not be acceptable to the regulator since you technically shouldn’t start the “retention clock” until the beginning of the subsequent calendar year.
To summarize my observations from the field, this post is sharing 3 retention label approaches to address the CY+x years requirement, each with pros, cons, and behavior limitations:
APPROACH 1: “Created date” retention label (extended retention)
Check with your regulator to see if they approve retention for 1 year longer than the requirement. From my experience in the field, sometimes the retention requirement is written as a minimum and therefore, it may be acceptable to retain for longer (in this case, 1 year longer). If we take the CY+1year retention requirement, this approach will guarantee content is retained from a minimum of 1 to a maximum of 2 years past the Calendar year it was created in.
In this approach, content is retained based on the created date… if the retention requirement was CY+1y, you would create a retention label to retain for 2 years past created date and apply to relevant content needing to comply.
Alternatively, you could use the last modified date instead of the created date on your retention label definition if that suited your retention schedule requirements.
E.g., retain for CY+1y after the last file modification.
Retention duration examples with the ‘created date’ extended retention approach:
- File created on January 1, 2020 would be retained until January 1, 2022 (same retention as if you were to start a 1-year retention based on the start of the 2021 calendar year)
- File created on July 1, 2020 would be retained until July 1, 2022 (6 months longer than if you were to start a 1-year retention based on the start of the 2021 calendar year)
- File created on December 31, 2020 would be retained until December 31, 2022 (1 year longer than if you were to start a 1-year retention based on the start of the 2021 calendar year)
The strictness of the retention requirement will dictate whether this approach will be an option for you. Check and verify with your regulator as you must stay within the spirit and intent of the File Plan.
The upside of this approach is its design simplicity. If this approach satisfies your regulator, it is definitely the simplest of the 3 approaches.
The downside of this approach is it may not be sophisticated enough to meet your regulator’s retention requirements. You may be required to dispose of content as it’s exactly stated in the File Plan and not a year after.
APPROACH 2: Labeled date retention label
Auto-apply a ‘based on labeled date’ retention label with the condition: created=”last year”. This will automatically apply the retention label to content once the calendar year is past. (assuming there isn’t another retention label already on the content)
This is the retention label settings for retention label, Exec – Briefing Notes:
Once saved, create an auto-apply label policy to apply the above retention label to relevant sites using this KQL condition: Created=”last year” AND spcontenttype:document (and whatever other conditions are relevant to your content).
Here are results from my tenant:
- Retention label name: Exec – Briefing Notes
- Auto-apply policy name: Apply to Exec Briefing notes last year
Since the auto-apply label policy will apply the retention label within a 7-day window, the retention clock will start within the first 7 days or so of the new Calendar Year for all content created last year.
The upside of this approach is 1 auto-apply label policy is all you need for each retention label since the date condition, Created=”last year”, will automatically reference the prior year at the start of the new Calendar Year causing the labels to automatically populate on the previous year’s content.
The downside of this approach is there may not be a retention label applied to content until after the next Calendar Year begins. This is why you must plan ahead and assess this risk.
APPROACH 3: Event-based retention label
Using event-based retention labels along with a Calendar Year-end event is another way of starting retention; however, this approach can be used to start retention for numerous retention labels all relating to the event. Here’s how you’d do this…
Create a tenant-level term set for Calendar Years:
Create a site column (recommend creating it in the tenant-level Content Type Hub and publish it to all sites so they can all use it) referencing the tenant-level managed term set from above.
Add the site column to any libraries containing content needing to comply with a CY retention requirement across your entire tenant. (for the SharePoint information architects out there, this can also be added to a custom content type if that suits your requirements). Ensure the calendar year is filled in on all content under a CY retention requirement.
Tip: ensure the column is configured to set the current Calendar Year as the default each year.
Map the crawled property for the Calendar Year managed metadata column to a RefinableString## managed property. Ensure the correct search results are retrieved when entering a test query in the Microsoft Search or Content Search box: RefinableString##:’2021′
Create an event type for the Calendar Year (CY) event… I called mine Calendar Year-end
Define as many event-based retention labels as required for each of the unique CY retention requirements you have. All of them should be associated with the same event type, Calendar Year-end. Using the retention schedule example table from the start of this post, these are the 4 retention labels I defined, all associated to the same event type, Calendar Year-end:
Ensure content across your sites under a CY retention model have one of the CY retention labels applied through any of these means:
- manually set
- defaulted at a folder or library level
- applied thru Power Automate/custom code
- SharePoint Syntex document understanding model
At the start of each Calendar Year (near after January 1), trigger the retention event by using the Calendar Year-end event type. You must provide enough time for the back-end processes to index all content for the previous calendar year before triggering the event. This will ensure you’ll pick up all content tagged with all retention labels associated with the event type!
Include this condition: RefinableString##:'<previous CY value>’ in the event trigger. In this image, I’m triggering the event for all content tagged with 2021 in the CY column and any retention label associated with the Calendar Year-end event type:
After the back-end process has processed the tenant locations looking for all retention labels for the Calendar Year-end event type that are ALSO tagged with a calendar year of 2021, retention begins on them and a new column, Label Event Date, is automatically added to any affected libraries.
Below are library images from 2 different sites with different calendar year retention labels applied, all triggered by 1 event:
The upside of this approach is one Calendar year-end event can trigger retention to start across multiple retention labels all associated to that event type (since this event only occurs annually, you could trigger the event either manually or automated). Another upside to this approach is the retention label will be on the content ahead of the CY event allowing you the ability to control the immutability of the record.
The downside of this approach is the requirement of some information architecture to hold the Calendar Year metadata and some familiarity with how event-based retention works. I also feel this approach is the most complex of the 3 and requires the most up-front planning.
I’m encouraged by the options available to implement CY retention. I want to stress to my reading audience how important it is to plan ahead, work with your regulators, involve your Compliance professionals and SharePoint information architects, and test the end-to-end process in a demo tenant before doing the same in your production environment.
Thanks for reading.
Thanks for the descriptions! For Approach 3, event based retention labels, you do not list auto-apply as one of the acceptable ways to apply labels. Does auto-apply not work with this Approach?
Hi Eric, I have not had consistent success with event-based retention labels being auto-applied to content which is why I intentionally didn’t include it. I continue to test and provide feedback to Microsoft on this.
Joanne, very interesting. Are you able to share any more details on what might not work with auto-apply of event based retention labels?