Calendar Year Retention Options in Microsoft 365

Reading Time: 8 minutes

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.

[Update January 2024] I have included an additional approach (3B) that uses the built-in created date as a condition to trigger the retention event at the end of the Calendar Year with an event-based retention label. Option 3B is now my preferred option for Calendar Year retention due to the reduced configuration required for event-based retention.

To summarize my observations from the field, this post is sharing 4 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 3A: Event-based retention label with custom metadata

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.

---

APPROACH 3B: Event-based retention label with built-in created date

An improvement to Approach 3A is using event-based retention labels along with a Calendar Year-end event, but leveraging the built-in Created column in SharePoint to identify content that was created throughout the calendar year instead of a piece of custom metadata. This eliminates several setup steps for event-based retention and is my preferred method. Here’s how you’d do this…

Similar to Approach 3A, create an event type for the Calendar Year (CY) event… I called mine Calendar Year-end

Similar to Approach 3A, 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. 

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 (January 1), trigger the retention event by using the Calendar Year-end event type. Different than Approach 3A, you can trigger this retention event immediately since the query you are using is based on the Created date which is a property set by SharePoint/OneDrive that will never change.

Include this condition: created=”last year” in the event trigger. In this image, I’m triggering the event for all content created last year that also has any retention label associated with the Calendar year-end event type:

After the back-end Purview service has had time to find content created last year that also has a retention label associated to the Calendar year-end event type, the retention clock starts. In this image, I have an event-based retention label, DEMO – Publication, associated to the Calendar year-end event type. The column, Label Event Data, is automatically added to the library with the event date (in this image, January 1, 2024) since the Created date is last year (2023):

 

The upside of this approach is you get the same benefits as Approach 3A, but with an additional benefit of using the built-in Created SharePoint column. This means no metadata needs to be set and no search schema configuration is required. Much simpler. You can also trigger the event immediately on January 1 of the new CY.

The downside of this approach is it cannot be backdated to calendar years prior to last year as it is relying on the built-in Created column and the “last year” date interval reserved keyword (I.e., you can’t use this approach for applying retention to migrated content that was created earlier than last year – if that is a requirement, I recommend using Approach 1 or 3A). Approach 3B also requires you to trigger the Calendar Year-end event annually, but that is a minimal downside.

---

Closing thoughts

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.

-JCK