Those of you paying closest attention to Microsoft 365’s Compliance Center might well have noticed the introduction of a ‘Records Management Settings’ page a few months ago. In this post I will discuss the settings provided on this page and explain the effect of applying them in your tenant.
The Record Management Settings page can be accessed by clicking on the ‘cog’ icon that has been added towards the top right side of the ‘Records management’ area in the Compliance Center (NB, this is not to be confused with the cog icon in your Microsoft 365 suite bar, which is located almost directly above!)
Currently, the settings page provides the following four global on/off switches, but no doubt we will see this list grow over coming months:
Allow users to delete items on OneDrive
Allows users to delete items on SharePoint sites
Enable record versioning
Allow editing of record properties
Deleting content labelled for retention
The first pair of new global configuration options determine whether users can delete content that has been tagged with a retention label. The controls are almost identical in function, with one determining whether labelled files can be deleted in OneDrive, with the other providing the same function for SharePoint.
While at face-value the functionality provided by these controls seems pretty obvious, it is worth considering them in more detail when deciding how best to configure your tenant.
As I discussed in a blog post at the time (See: SharePoint Retention Labels align with OneDrive to use the Preservation Hold Library (robbath.co.uk)), last summer Microsoft released an update that changed the way that retention labels protected content. Prior to this update, when users attempted to delete an item protected with a retention label, they were presented with an error message explaining why the file couldn’t be removed. However, since August last year when users delete files that have been tagged with a retention label, the file disappeared, but (often unbeknownst to the user involved) was actually being caught and stored behind the scenes (in a semi-hidden location called the ‘Preservation Hold Library’). However, the introduction of the new pair of configuration controls on the Records Management Settings page has placed the choice back in your hands, by allowing you to decide whether or not users can delete content protected with retention labels.
When viewed purely from a user perspective the choice might seem obvious – leaving these controls enabled removes some of the frustration that was experienced when users were unable to delete their unwanted content. However, as the deleted item is caught and retained in the Preservation Hold Library, it is still in the possession of the organisation and as such needs to be included within the scope of information rights requests. However, the real problem here is the fact that content cannot be deleted out of the Preservation Hold Library (not even by administrators). This means that as soon as items are caught and moved into this location, they will continue to be stored there for the remainder of their retention periods. This means that even if there is a legitimate need to delete the item (such as the file containing PII or being subject to the right to be forgotten) you will have no option but to continue to retain the items, potentially putting you at risk of breaching your legal / regulatory obligations. As such, the risk of leaving these settings in their default ‘enabled’ state is fairly significant.
While I can’t tell you what will work best in your organisation, for me the risk of having content that you need to delete, but are forced to retain, is very significant. I’d personally err on the side of caution and consider disabling these controls.
Configure record versioning
The next option on the Records Management Settings page allows us to control record versioning.
Any of you who use Record Labels (as opposed to Retention Labels) will no doubt have been aware that Microsoft rolled out a fairly significant change to the way that they work at the end of 2021. All of a sudden, users were given the ability to lock or unlock any record at will, effectively allowing your team to choose to disable immutability and edit previously locked records.
The way that this works is that each time a record is unlocked a copy of it is captured and stored in the ‘Preservation Hold Library’. This means that if a record is locked and unlocked multiple times, you will be storing multiple versions of the record behind the scenes, each of which will be subject to their own retention. As mentioned above, once in the Preservation Hold Library content cannot be deleted, forcing you to keep it for the remainder of its retention period – even if you have legitimate need to dispose of it.
While I think that I understand what Microsoft has attempted to do here, I still find the whole concept of record versioning a little confusing. For me when a record is immutable it should remain immutable (otherwise it really wasn’t immutable in the first place).
While records versioning is enabled by default in the Records Management Settings page, I’d personally encourage organisations who want to make use of record labels to consider disabling this control. Doing so will prevent users from being able to unlock records, ensuring that they stay immutable, while also allowing you to delete them in the future if you have legitimate need to.
Of course, at this point some of you might well be (correctly) pointing out that if we disable the record versioning option on the Record Management Settings page, that record labels will become rather awkward to use. You see, with the record versioning setting disabled, when we apply a record label to a file it will be immediately locked, preventing any further changes. As such, record labels cannot be applied until after the content has been created and is no longer being modified. However, the out of the box approach for this would require users to manually apply record labels to their files after they have finished updating them – something I think we can all agree simply won’t happen in almost any ‘real world’ scenario.
So why am I suggesting that it’s plausible to consider disabling this setting?
My answer is that organisations who wish to automate the closure of an aggregation (say all of the content in a site, library, document set or folder) might wish to disable this setting. This automation would require some amount of customisation, but result in the ability to dynamically lock your content when it is no longer being modified. In other words, with an integrated process you’d be able to reliably make content immutable without manual steps. This might, for example allow you to lock content when a project closes, or when an aggregation is reviewed. Obviously, I recognise that this sort of bespoke logic might be outside of the reach of many, but it’s certainly a path that organisations wanting immutable records, without the limitations of relying on the Preservation Hold Library, might wish to consider.
Editing Record Properties
The final configuration option found on the ‘Records Management Settings’ page is the ability to control the editing of record properties. This might not sound like much, but it’s something I’m excited to see introduced into Microsoft 365 as it finally allows us to ensure that the metadata applied to records cannot be modified.
Until this control was added, record labels have worked in a rather inconsistent manner:
When applied to an item in a SharePoint list, a record label would lock all of the columns of metadata, preventing changes.
When applied to an item in a SharePoint library, a record label would lock the file itself, but would allow users to continue to modify the record’s metadata.
This has been a source of some frustration for several of the organisations I’ve worked with over the past few years, who expect immutability to apply consistently to both the record and its associated metadata. Thankfully, when disabled, this new setting allows us to do exactly that – and is certainly something I will strongly encourage anyone using record labels to consider.
Conclusion
It’s always great to see new records management options being introduced to help us to shape the architecture of our tenancies. The Records Management Settings page provides much needed flexibility to allow every organsiation to determine their own approaches – something I strongly welcome and hope to see enhanced going forwards.
My personal feeling is that disabling all of these current settings is probably the best approach for many organisations – but I would suggest not doing so until you have a clear understanding of the way these capabilities function. I expect that Microsoft will continue to provide us with further records management configuration options on this page in the future. While I welcome these new settings, making decisions at a tenancy-level isn’t always appropriate (especially in scenarios where more than one organisation share a single Microsoft 365 tenant). As such, I hope that Microsoft will consider allowing us to make decisions at a lower level in the architecture, perhaps by providing options to apply different records management configurations to different SharePoint sites.
I hope that this post has helped to explain the (relatively) new Microsoft 365 Records Management Settings page - don’t hesitate to get in touch if you have any questions!
Comments