Is your organization in the planning stages of applying retention controls across Office 365? A recent Twitter poll I did revealed the majority of respondents were!
Whether this is representative of the larger population or not is impossible to know, however I suspect there are conversations and planning going on in many organizations right now to determine exactly where and how to begin. To help get you started, I’d like to share an approach I’ve come to embrace for both planning and implementing it.
To apply retention at scale across Office 365 workloads, I believe a Crawl-Walk-Run-Sprint approach is helpful for getting you there. This model fits the implementation of retention controls within Office 365 perfectly, particularly if you’re starting from square one.
What is meant by Crawl-Walk-Run-Sprint? It’s a measured, gradual approach for adopting a technology or new way of doing something to elicit a high-degree of success while allowing for incremental improvements along the way.
TLDR? Skip down to the summary section to see what steps are in each stage.
Before I explain how to apply this model, I first want to summarize my 5-step approach to configuring Retention in Office 365.
My Approach
Important to know:
Retention labels are published at a site collection level in SharePoint. Once published, a document library can be defaulted to the label, a library folder can be defaulted to the label, an individual document can be assigned the label or a label can be auto-applied based on content in the document. You can use disposition review on a label. Note: these are not Azure Information Protection labels!
Retention policies are also published at a site collection level but can be defined independent of a label. They apply retention at a site (container) level. End-users are unaware the policy is in effect – they can continue to add, change and delete content. You cannot use disposition review on content only covered by a policy.
Step 1: Define the Crown Jewel Labels
Crown jewel examples: Incorporation documents, Patents, Board Meeting Minutes, Executive Meeting Minutes, Contracts, Budgets, Policies, some Procedures, etc.
Step 2: Define the Boilerplate Labels
I use the term boilerplate to indicate a standard set of labels to be applied within your organization across all sites in your tenant and therefore should be reusable, time-tested, and well-understood.
By boiler-plating a standard set of labels across your tenant, it will be a consistent experience for end-users. To do this, identify the different types of retention classifications you will typically find within sites’ content across your entire tenant and define labels for each of them. You will want to big bucket the content to come up with these. My recommendation is to come up with a first-cut at these labels thru a joint working session between the Information Management team and the team in charge of end-user adoption. Determining these labels needs to be a joint discussion between these two teams because it’s critical we balance the regulatory retention requirements the organization has against the end-user experience. The intent is to eventually publish these labels to EVERY site in your organization so users will need to understand the meaning of each label to know when to apply it.
Boilerplate label examples:
- Business Record – Retain for 7 years after last modified, then review before delete
- General Team Administration – Retain for 2 years after last modified, then delete
- Convenience Copy – Retain for 1 year after last modified, then delete
- etc.
What is the right number of boilerplate labels? It depends. Not enough labels and the content may not all be covered at a granular enough level and appropriate retention may not be applied. Too many labels and the end-user will become frustrated with too many choices causing end-user experience to suffer. Although there’s no magic number of boilerplate labels you should publish, common sense says it shouldn’t be too high due to a diminishing end-user experience the higher it gets. My recommendation is to definitely keep this under 10. Even better? Under 5.
Step 3: Define the Targeted Labels
Targeted label examples: Project documents, Network diagrams, Official system documentation, etc.
Step 4: Define the “Auto-apply” labels
Auto-apply examples: Any document with a credit card, customer #, personally identifiable information, etc.
Step 5: Define the “Catch-all” policies
You can have numerous retention policies defined in your organization. A great idea is to map policies to different site templates. For example, if you have provisioned a Project Site Template and you have a requirement to retain all project content 2 years after the end of the project, you may want to have a retention policy specific for Project sites and publish it to them. This would ensure all project sites would have the same retention policy applied to content within it.
I really like the container model for applying retention (using Retention Policies) due to the growing number of collaboration sites being provisioned in tenants today. Tenant-wide policies, in combination with boilerplate labels, is one way of ensuring all content in collaboration sites is under retention across your tenant.
It will become very important for information management teams to follow up with collaboration site owners to review their content and to publish more specific labels to their site as required. It’s important to ask team owners the type of content they will be storing in their collaboration site prior to the site being provisioned – this can be done thru a site request form filled out by the site requester and is a good reason to implement a site-provisioning process in your organization!
As of the time of this writing (June 2018), you cannot publish a retention label to Microsoft Teams’ chat and channel conversations. You can, however, publish a retention policy to them, therefore if you need to apply retention to Teams’ chats and channels, you need to use a retention policy.
Crawl-Walk-Run-Sprint Model
Let’s get back to the Crawl-Walk-Run-Sprint model and how to apply the results of the above 5 steps against it.
Throughout all stages in this model, a common thread is end-user training. As more capability is introduced at each stage, make sure to educate end-users in your organization so they understand what the labels and policies mean for content they’re working with.
Crawl
Start with (some of) your crown jewels. This content is most at-risk and end-users who work with this content are usually aware of its importance making this a relatively easy place to start. Design the appropriate information architecture for how you’ll store each of the crown jewels in Office 365, create Retention labels for them and publish to the workload(s) they live on whether it’s a SharePoint site, Office 365 Group, or Exchange email.
Note: although you can also publish a retention label to OneDrive account(s), you should never be storing crown jewels there!
Walk
Add the remaining crown jewels if you haven’t done them all in the Crawl phase as well as the targeted labels I referred to above. This is also a great time to test out your boilerplate labels with a small cross section of teams across your organization as a proof-of-concept (POC) to allow for feedback and adjustment(s).
Don’t be afraid to go back to the drawing board if the first-cut at your boilerplate labels didn’t work. It’s important for these label names to resonate with end-users as they will eventually be published to every site in your tenant so you need to get this right!
Run
By now, you should have a good understanding of the Retention Label adoption across your organization for the crown jewel, targeted, and the POC boilerplate labels (Label Activity Explorer – image). Based on feedback you receive from the POC, make any required adjustments to the boilerplate labels and publish them to all remaining sites across your tenant.
Sprint
Now is the time to include any auto-apply labels and default Retention policy(s) you’ve defined. This will ensure ALL content across Office 365 is covered by retention whether or not a retention label has been applied.
Summary
Here are the steps in each stage:
- Crawl: publish some Crown Jewel retention labels
- Walk: publish remainder of Crown Jewel labels, Targeted labels, and POC Boilerplate labels
- Run: publish finalized Boilerplate labels to all sites across tenant
- Sprint: publish Auto-apply labels and Retention policies
I’m currently recommending this model with organizations I work with and feel it’s a manageable, pragmatic approach to implementing retention at scale.
Thanks for reading.
-JCK
- Credit: Photo by Hunter Johnson on Unsplash
- Credit: Photo by Church of the King on Unsplash
- Credit: Photos by rawpixel.com from Pexels