With millions of new users this year, Teams has quickly become one of the most important information storage applications in many organisations. As we begin to return to the workplace, I think it’s already pretty clear that work patterns will change for many. I’d wager that the transition into Teams will persist and it will become the central tool that many of us work with daily.
The reason people have jumped into Teams is obvious, not only is it an excellent communication tool, it also provides easy access to group working conversations and content. However, while users enjoy the ease of use and collaboration benefits brought by Teams, many people working in information management and compliance are now retrospectively wondering how to best control, govern and importantly apply retention to content in Teams.
I thought a blog on this subject was well overdue!
There are really two viable approaches to retention in Microsoft 365. (Yes, there are also legacy concepts, including Record Centers and In-Place records management – but I’m going to ignore these outdated methods for brevity.) Both of these approaches can be applied to different areas of Microsoft 365, so becoming familiar with their capabilities is essential if you are looking to design a tenancy-wide retention architecture.
Retention Polices are virtually hidden from end users – even to the extent that deleted files are caught behind the scenes within hidden containers. As such, users can’t see (or tag) content with a Retention Policy. To apply Retention Polices to your content you need to use either of these approaches:
- Applied to all content in a given site – in the context of Teams, this means that all content stored in all the Files tabs across all Channels in a given Team are subject to the same policy.
- Automatically applied – if you are lucky enough to have a premium licence1, you can automatically apply Retention Polices to files. This currently works by applying retention to all content that contains either a specific phrase/keyword or ‘sensitive information’ (such as a credit card number or a national insurance number).
Unfortunately, Retention Policies do not provide a mechanism for making content immutable. As such, Retention Policies cannot be used to lock files as records.
At the end of the retention period Retention Policies allow you to either automatically delete content, or to ‘do nothing’ (which I’ve never really understood the value of). Unfortunately, Retention Polices don’t currently offer the ability to trigger disposition reviews at the end of the retention period.
It’s probably best to think of Retention Policies as a way of disposing (of) lower value content, than for long-term preservation of important files. I also find that Retention Policies are a really useful safety net – a backstop to catch anything that isn’t governed by Retention Labels.
Unlike Retention Policies, Retention Labels are visible to users. This is most apparent when a user attempts to delete content that has been labelled – instead of being sent to the recycle bin, the following message is presented: