There are many things to consider when applying retention to your SharePoint Online content, and each decision you make will have follow-on effects to be aware of. I’m writing 4 posts to highlight 4 key questions to answer when configuring Office 365 retention and will identify some pros, cons, and examples surrounding each:
This post is the fourth in the series, Retention in SharePoint Online: The Where, What, How and When, and answers the all-important “WHEN” question:
- Part I: Retention in SharePoint Online: The “WHERE” answers the question “Where should retained content live?”
- Part II: Retention in SharePoint Online: The “WHAT” answers the question “What type of retention should be applied?”
- Part III: Retention in SharePoint Online: The “HOW” answers the question “How should the retention be applied?”
- Part IV: Retention in SharePoint Online: The “WHEN” (THIS POST) answers the question “When should the retention start?”
I think the image below sums up the retention scenario across Microsoft 365. Knowing you need it is only scratching the surface (which is partly what this blog post series is addressing)…
Let’s answer “The WHEN”…
You’ve decided where you’ll retain your content, what type of retention you’ll apply, how you’re going to apply it, and now you need to decide when retention will start. This may initially seem like a simple decision, however you must consider the options available to you to ensure the start of the retention/deletion period is triggered at the right time. I’ll cover options for both retention policies and retention labels for content stored in SharePoint Online.
The options available will depend on whether you’re using a Retention policy or a Retention label (check out the WHAT post for that). I’ll list the options available and give an example for each.
Options to “start the clock” for a Retention Policy
In all examples, ‘x’ is a number of days, months, or years. I’ll provide an example of ‘Retain for’ and ‘Delete after’ for each one.
#1 – Retain for ‘x’ based on created date
Use-case example: “Retain all content on an Archived site for 10 years”
This is a good option if you’re controlling when documents are copied to a specific site (for example, an Archive site) and you have regulatory requirements to ensure content on the Archive site is retained for a specific period of time. Since the created date will be the date the document is copied, this model would work if you want the retention clock to start on that date.
Important to know…
If copying content to another site… the created date and last modified date will be the date it was copied.
If moving content to another site… the created date and last modified date will be what they were on the source site. With older files, this could be longer than the retention/deletion period on the new site so be careful when moving files as this could potentially delete them once moved to the destination site.
#1 – Delete after ‘x’ based on content’s created date
Use-case example: “Delete Teams chat messages 30 days after created”
This is a good option if your organization deems Teams chat messages as a liability and wants to ensure they aren’t discoverable past a certain period of time. This does not prevent an end-user from manually deleting a Teams chat message prior to 30 days, however it ensures all Teams messages are automatically deleted at the 30-day mark. (Note: the back-end process may take up to 3 days to delete the message so technically they may be discoverable for up to 33 days)
#2 – Retain for ‘x’ based on content’s last modified date
Use-case example: “Retain (Access Request) forms stored on a site for 8 years, then delete”
This is a good option if you want to ensure important work (filled out forms in this case) is retained for audit and regulatory reasons, while ensuring you aren’t “over-retaining” the content when it’s business-use is gone and the audit/regulatory period is over. By using the last modified instead of the created date, you are protecting the content actively being worked on for a longer period of time. If you stored forms with the same retention period on the same site, this would be a good model.
#2 – Delete after ‘x’ based on content’s last modified date
Use-case example: “Delete stale Team Collaboration Work after 8 years”
This is a good option if you want to control content sprawl and prevent redundant, obsolete, and trivial (ROT – Controlling the ROT in SharePoint Online) content from filling up your storage quota and messing up your search results, something many of our organizations have experienced in the shared drive world. By using the last modified instead of the created date, you are protecting the content actively being worked on for a longer period of time, presumably because it is more relevant/important to the team. And because this is a deletion policy, it does not prevent an end-user from manually deleting content they no longer want.
You would not want to exclusively use this option if you have specific retention requirements for other content on your site. In that case, you should (also) apply a retention label to target that content.
Options to “start the clock” for a Retention Label
In all examples, ‘x’ is a number of days, months, or years. To keep the post ~short, I’ll provide an example of ‘Retain for’ for each one and I’ll leave the ‘Delete after’ example up to your imagination! 🙂
#1 – Retain for / Delete after ‘x’ based on created date
Use-case example: “Retain tax forms 10 years after created, then delete”
This is a good option for forms you upload to your environment from other source systems to meet your regulatory requirements. In this case, the date you upload the form will be the created date so the retention timer can start based on that date. This will ensure the content is retained for a minimum length of time and then properly disposed of.
If you have different retention for different forms, you can store them in separate libraries, each with a different default retention label, or separate folders within one form library, each with a different default retention label.
#2 – Retain for / Delete after ‘x’ based on last modified date
Use-case example: “Retain board meeting minutes 10 years after last modified, then delete”
This is a good option for content that is collaborative in nature, but still requires retention for either business-value or regulatory reasons. In this example, board meeting minutes may be worked on past the meeting date so it’s important for the retention timer to start after the last modification.
Note: depending on your regulatory requirements (and license), you may want to inject a disposition review prior to permanent deletion.
#3 – Retain for / Delete after ‘x’ based on labeled date
Use-case example: “Retain approved financial statements for 7 years”
This is a good option if you’re controlling the approval process (Power Automate Flow) on a piece of content and automating the application of the label (although the label can also be applied manually). In this example, the application of the label will coincide with the financial statement being approved and will start the retention timer at that moment.
#4 – Retain for / Delete after ‘x’ based on an event date
Use-case example: “Retain contracts for 5 years past contract end date”
This is a good option for any event-based trigger (Employee leaving, project closing,…). In this example, the event to trigger the retention period to start is the contract end date. There are several ways to implement this and I have blogged about this extensively. Please refer to the below posts for reference:
Thanks for sticking with me. I hope you found this helpful and I’d love to hear your examples of when you’ve used these options across SharePoint.
This Retention series covered where to store your retained content, what type of retention to apply once you put it there, how to apply it, and when to trigger the retention. I hope you found it helpful and can use it to start building your own retention solutions across your tenant.
Good luck and reach out for comments, feedback, and questions!