A fairly significant change to the way that Retention Labels work is being released across SharePoint Online this August, which will help to make the way that retention is applied to content far more consistent across Microsoft 365. The update will also remove some of the barriers that users currently experience when using Retention Labels. Record managers, as not only will it affect both the length of time that records are retained for but also the guidance that they give to users, will need to understand the effect this update presents and will likely need to plan retention labels and guidance appropriately to avoid content being retained for longer than necessary.
So, what is being changed?
Retention Labels in SharePoint Online are effectively being brought into line with many of the other retention capabilities found across Microsoft 365. Rather than preventing a user from deleting a labelled item altogether, which is the current behaviour, this update will see Retention Labels work in the same way that they do in OneDrive.
At the moment, when a user attempts to delete a labelled item, the deletion will be prevented, the file will be retained, and the user will be presented with an error message, as below. This message has been a source of frustration for many end-users, especially if all that they are trying to do is delete a draft or note.
After the new update has been rolled out in August, users will no longer be confronted with this message. Instead, when a user deletes an item, it will be removed from the library and appear to have been deleted. What the user might not know is that what actually occurs is that the deleted item is caught and moved into the given site’s Preservation Hold Library. In this Library, the item will be retained for the remainder of its retention period and will only be visible to Site Collection Administrators and to eDiscovery / Content Search capabilities in the Compliance Center.
What is the effect of this change?
Most end-users will probably not even notice this change, and those that do will likely wonder where the error messages that prevented them from deleting items have gone. From a user perspective, Retention Labels will become a lot less obstructive – staff will appear to be able to freely delete content unimpeded. Certainly, this change is a great improvement to the user experience, helping to remove one of the larger frustrations that Retention Labels presented.
Another outcome of this change will be a far more consistent retention architecture. With this alignment, some of the complexity in the story of Retention Labels and Retention Policies will have been removed, which should make retention easier to understand. It wouldn’t surprise me to see this more consistent approach making it easier for Microsoft to extend the retention capabilities further. With a less complex architecture to work around, we might see a whole range of future improvements – I for one would love to see an enhanced retention monitoring/reporting interface at some point in the future. Certainly, it’ll be exciting to see how this change allows Microsoft to extend the retention capabilities over the next few years.
Some organisations have already expressed caution around this change, simply because of the increased likelihood that content which a user thinks they are deleting might instead be routed to the Preservation Holds Library, and consequently retained for much longer than perhaps intended. This could, in theory, be a quite significant obstacle in scenarios where users are actively trying to delete content containing PII that they no longer have a reason to hold – in theory, there is a chance that deleting these files might instead cause them to be retained for months or potentially years longer than they need to be without the deleting user being aware.
I think that there are some good steps that organisations can take to mitigate against this scenario from occurring too frequently. Firstly, when planning your Retention Labels it’s important that you identify the purpose for each label:
• If the label is intended to ensure a minimum retention period, a standard retention label should be used. When deleted earlier than the minimum retention period the item will be caught and retained behind the scenes.
• If instead the label is intended to ensure timely deletion (c.f. PII), make sure that you configure your retention label to “Only delete items when they reach a certain age”. When a user deletes an item classified with a label that has been configured in this way, it will be sent to the site’s recycle bin and deleted in the standard c. 90-day process.
Of course, there will be some content that doesn’t easily fit into either of these two categories, a good example being a draft document. If a draft document is created, in most scenarios I’d imagine that a standard retention label would be applied to it. However, if the draft is abandoned and deleted, this would see the file being retained for the remainder of the retention period in the hidden Preservation Holds Library. This will naturally mean that, without regular administration, one consequence of the forthcoming change will be an increase in the amount of low-value content that is retained. One redeeming factor is that content of this kind is typically considered to be redundant, obsolete or trivial (ROT) and rarely would be liable to any legal or regulatory mandate for deletion.
Overall, I think this change represents a good step in the right direction. It helps simplify the experience for users and provides a much more consistent approach to retention across Microsoft 365. This change could be frustrating for organisations who have already used standard retention labels to protect content that they need to ensure is being deleted (such as PII), but hopefully it won’t prove too challenging to retrospectively re-wire existing systems with labels that permit deletion.
Do get in touch if you need any advice or guidance on how to optimise your compliance in Microsoft 365.
Further information about this change can be found in your tenant’s Message Center (item: MC264360) or in Microsoft’s Roadmap (item: 82063).