This post explores approaches provided in Microsoft 365 for managing Microsoft Teams Chat and Channel Posts as records. If you’re interested in finding out more about applying retention to files stored in Teams, check out my other blog here: Retention in Microsoft TeamsWhile organisations tend to use a tapestry of different tools to support collaboration, over the past couple of years Microsoft Teams has started to consolidate its place as the primary tool that many organisations use to support internal (and often external) collaboration. For the organisations that have adopted it, Teams has been slowly replacing email as the primary mechanism for information exchange. This has led to Records Managers starting to consider how information stored in Teams can be managed as records.
Teams, of course, is just the latest step in a trend that has been progressing for years, with successive technologies changing the way that we collaborate. Correspondence has shifted from the postage stamp to the emoji in less than four decades. Each of the new technologies that have prospered have made the process of collaboration faster, allowing information to be exchanged in seconds rather than minutes or days. With speed comes brevity: each successive technology has seemingly divided the information that is being exchanged into smaller and smaller bite-sized chunks. From typed documents that often contained multiple considered points, the same information is now frequently instead communicated via a series of emails, Tweets, WhatsApp chats and, of course, the subject of this blog, Teams Posts and Chats.
This transition presents somewhat a quandary for Records Managers. While a single document of value can be identified and retained relatively easily, how can we govern information that is being exchanged in dozens or even hundreds of bite-sized messages? To me, this is a fundamental issue for Records Managers today: how can we take approaches designed to cater for considered files and apply them to information that holds the same value, but is spread over multiple small messages and chats?
While the answer to this conundrum isn’t clear, there are several potential solutions that I’m fairly certain we need to avoid:
Firstly, whatever we do cannot involve inhibiting ways of working. Trying to apply the brakes, or in any way slow down the exchange of information, will only result in user frustration and inefficient ways of working, or intentional efforts to circumvent procedure. One instinct we need to curb is that of trying to take away the technologies that support the way staff collaborate. Information governance must not impede the ease of information exchange. To be clear on this point, I’m certainly not encouraging the dangerous rabbit-hole of self-administration often known as shadow IT! I would like to see each organisation providing technology that empowers their staff to work together efficiently, so that the temptation to turn to un-governed cloud software is minimised. Instead, we need to ensure that the software provided and controlled by the organisation can meet rapid collaboration needs while still being governed.
We can’t limit or dictate the nature of the discussions that people hold in specific technologies. Telling staff that they can only discuss low-value topics in Teams and to ensure that more important exchanges are held in other technologies simply doesn’t fly. Once they have access to Teams, staff will be discussing all manner of subjects, some might be sensitive, others might be highly important, while others might contain Personal Identifiable Information (PII). Any organisation who have instructed their staff to avoid using Teams Chat for important conversations are, in my mind, putting their fingers in their ears and hoping the problem will go away.
We also need to avoid the temptation to get users to create separate records of their activity. Put simply, staff typically won’t have time (or the will!) to make a separate record of a communication, decision or agreement. By and large, this means that the governance that is applied to any exchange of information needs to be as automated as possible – if users can’t be relied upon to tag a document, in most cases they certainly can’t be expected to create a file for the sole purpose of ensuring a record is kept. (I’m sure there are plenty of exceptions, especially in legal and financial scenarios!) This inevitably means that Teams, and specifically Teams Chat and Channel Posts really need to be treated as systems of record and not merely systems of engagement. We simply cannot reasonably expect staff to record their conversations of value elsewhere.
It’s relatively simple to produce a list of “don’ts”, but it’s much harder to provide a corresponding list of “dos”.
Chat and Channel Retention in Teams
While Microsoft provides powerful retention capabilities across the tenancy, which are improved and enhanced on a regular basis, options for managing records in Teams Chat and Channel Posts are still rather meagre. The only retention option for Teams Chat and Channels Posts comes in the form of the Retention Policy functionality. Unfortunately, as of the time of writing, Retention Labels cannot be applied to Teams Chat or Channel Posts.
Retention Policies offer a broad-brush approach to records management, and they apply equally to all of the content in a given area of Microsoft 365. The different types of messages in Teams are handled in slightly different ways:
Teams Chat messages are governed by Retention Policies that are applied to the user. This means that all of the 1:1 Chats for the given user will have the same retention applied to it, irrespective of the value of that conversation!
Teams Channel messages are governed by Retention Policies that are applied to the Team. This means that any message added to any of the Channels in a given Team will have the same retention applied to them, again, irrespective of the value of the given conversation.
… but what about messages added to Teams Meetings?
One concept that I don’t think many Teams users (or even Microsoft 365 Administrators) have fully got their heads around yet is that there are two very distinct types of meetings held in Teams:
Channel Meetings – any posts made in a Channel Meeting are governed by Retention Policies that are applied to the Team. It’s also worth noting that in a Channel Meeting, any associated meeting recordings, whiteboards, or uploaded files are stored in the SharePoint site associated with the given Team (that the Channel is in).
Non-Channel Meetings – any posts made in a non-Channel Meeting (sometimes referred to as a 1:1 meeting) are governed by the Retention Policies that are applied to the user who created the meeting. Associated meeting recordings, whiteboards and uploaded files are stored in the OneDrive for Business workspace of the user who created the meeting.
In my experience, Channel Meetings are a relatively rare occurrence – my guess is that the vast majority of meetings in Teams are set up as 1:1 Meetings. To the best of my knowledge there are only two ways to create a Channel Meeting:
When you create a meeting from a given Channel within the ‘Teams’ section of Teams
When you create a meeting in the ‘Calendar’ section of Teams, and manually select a Channel to associate the meeting with
If you create the meeting in any other way, for example via the Outlook calendar, then the meeting will not be associated with a Channel and will therefore be created as a 1:1 or non-Channel Meeting.
The reason I’m spelling this out is because I feel many organisations are allowing important meetings to be run and therefore retained under the account of the user who has created the meeting. Perhaps we need to encourage our colleagues to understand how to create Channel Meetings? Although, being honest, I’m not convinced encouragement will lead to a significant change in behaviour.
Retention Policies
Given that Retention Policies are our only option within Microsoft for managing Teams Chats and Channel Posts as records, let’s take a closer look at the way that they work.
Retention Policies are nowhere near as flexible as Retention Labels. Not only do Retention Policies force us to apply the same retention to all of the Chats a given user has or to all of the Posts in a given Team (irrespective of the value of the conversation), we will also see that Retention Policies present a records manager with several other limitations:
Retention Policies cannot make content immutable – users can freely continue to modify Chats and Posts that they have made, even when a Retention Policy is applied to them.
Retention Policies are largely invisible to users – staff can think that they are deleting Chats and Posts, but these will be caught behind the scenes and retained for the remainder of their retention period. This is great for ensuring content is retained – but not so good when a user has good reason to ensure that content is deleted sooner.
Retention Policies cannot trigger a disposition review – at the end of the retention period Chats and Posts can either be automatically deleted, or otherwise, nothing happens to them. It took me a while to understand any potential application for the ‘nothing’ option, but it could be useful in scenarios where you want to ensure that a given type of content is retained for a minimum legal/regulatory duration – but aren’t concerned about its timely deletion.
Balancing the risk
For many organisations GDPR and ensuring the timely deletion of personal identifiable information (PII) is the most pressing consideration when considering governance for Teams Chat and Channel Posts. A significant fine for failing to delete information you are no longer allowed to be processing is seen as a bigger risk than ensuring that information of value is appropriately retained for longer.
Many organisations feel that they have no viable choice – they simply cannot afford to take the risk of allowing personal content to be accidently retained, so opt to use Retention Policies to apply very short-term automated deletion to all of their Teams 1:1 Chats (and very often to their Channel Posts too).
Recently, several of my clients have started asking me for information about how fast Retention Policies can be as automatically deleting messages.
Gone in 24 hours
The shortest duration that can be set for a Retention Policy is one day. Although, if you’ve ever tried to apply this to your Teams Chat or Channel Posts, you might have noticed that messages are not deleted 24 hours after they were first created. My incredibly talented colleague Ravi Bamrotiya has spent some time investigating precisely what happens when a one-day Retention Policy is applied to a message in Teams – the results are a little surprising.
Under the scenes, the process that deletes Teams Chats that have reached the end of their retention period doesn’t run on a daily basis, but instead seems to run twice each week. When the process runs it doesn’t automatically delete all of the messages that have reached the end of retention, but only those messages that reached the end of retention before the process last ran.
In our test tenancy, we noticed that Chats were only being deleted every Friday and Sunday (although I wouldn’t be surprised if the days changed in different tenants!). Every Friday all of the Chats that reached the end of retention before the preceding Sunday were deleted (but the Chats that reached their end of retention during the week (Monday-Thursday) were not). When the second process runs on the Sunday, it again seems to delete all of the Chats that reached the end of retention before the preceding Friday. What this means is that there is some variation in how rapidly a Teams Chat message that has a one-day Retention Policy applied to is deleted:
At fastest a chat message created on the Thursday should reach the end of retention on the Friday and should be deleted on the Sunday only c. 72 hours after it was created.
At slowest a chat message created on the Friday should reach the end of retention on the Saturday. These messages are not deleted by the Sunday process, but instead deleted by the process running on the following Friday. I.e., the message is deleted c. 1 week after it was created.
Channel Posts follow an almost identical “twice a week” deletion process, but the messages are instead deleted on different days of the week.
Again, I should stress, that the precise nature of the deletion processes could easily be configured differently in different tenants and in different regions.
Update from Microsoft
Since writing this blog, we’re really grateful that Erica Toelle from Microsoft’s Compliance team in Redmond has been in touch and clarified that in some scenarios it can take up to 16 days before teams Chat or Channel Posts are fully deleted. See: Learn about retention for Teams – Microsoft 365 Compliance | Microsoft Docs
Thanks for the heads up Erica, really appreciate it.So, what's the solution?
I fully understand the urge to act with caution and seek to reduce risk by automatically deleting messages in Teams after a few months or days, but I have to admit that this approach doesn’t sit too comfortably with me.
Personally, I regularly refer back to information in conversations that occurred weeks or even months previously. This makes me fairly confident that any organisation who opts to delete Teams Chats and Channel Posts too routinely is very likely to be reducing the efficiency of their staff. Rather than being able to refer back to a chat for the information that they need, users are likely to disturb each other and ask for the information a second time.
I also recognise that many of the most important communications I have both internally and with clients are now happening in Teams Chat and Channel Posts. These conversations are not recorded elsewhere (and I don’t have time to transcribe them into a separate record). I’m confident that organisations who chose to routinely delete messages in Teams will certainly be losing much of their content of value – the decisions, the discussions and the authorisations to proceed.
I’m also not convinced that deleting all Teams messages after a very short retention would be easy to justify legally. If you are deleting down messages after a few days or months because they might contain PII, but are applying a longer retention (say 12 or 18 months) to files that have been classified because they actually contain PII, then I think you might be on somewhat shaky ground. I think that the conclusion that might be reached is that the retention period for the Chats and Posts was made artificially short – and while I’m not a legal expert, I’m not convinced that the justification would stand up too much rigor.
I’m not sure that this is a theoretical risk either, as we speak the Department for Digital, Culture, Media and Sport is being threatened with potential legal action for auto-deletion of their instant messages after only 90 days (see: Government facing legal challenge as DCMS admits use of automatically deleting messages (civilserviceworld.com)). The campaigners who are threatening the legal action argue that auto-deletion is causing a “lack of transparency [that] is an urgent threat to democratic accountability and to the future of the public record”. While, I certainly don’t have a legal background, I do find it hard to disagree that using retention to auto-delete instant messages might actually be putting an organisation at greater risk – you are actively destroying much of your information of value.
While I hope that the technology continues to improve to provide us with a better approach to fix this issue, right now, I’d suggest:
The minimum duration of a Retention Policy that is configured to auto-delete Teams Chat and/or Channel Posts should be no shorter than the retention period as you apply to PII for documents. From my experience, this would be no shorter than 18-36 months in most organisations.
A Capstone approach to records management for Teams Chat should be considered. 1:1 Chats for more senior users should be retained for much longer (and possibly even considered for archival).
Instead of encouraging staff to avoid using Teams for anything important or to make separate records of their Teams messages, consider instead asking them to avoid putting any PII in Teams Chat or Channels Posts. Consider making use of Sensitive Information Types to identify personal numbers, such as National Insurance or Passports numbers that are being added to Teams messages.
Consider whether you want to export copies of Teams Chat and Channel messages (including reactions!) for longer retention outside of Teams.
While there certainly isn’t a perfect solution, my view is that trying to sweep the records under the rug through rapid deletion of instant messages is the wrong approach: not only does it impede staff, but it also presents too much of a risk of seeing important records being lost. Especially in the Public Sector, I can’t personally see how short retention periods can really be justified for Teams Chat and Channel Posts.