[Updated August 2024] Included an additional option under The Fix
I have now worked with several customers who wish to exclusively use the auto-apply capability to apply a retention label to their SharePoint content. This means they have chosen not to publish any retention labels directly to any SharePoint site where they are auto-applying labels. The reason given for this approach is it removes the ability for end-users to select/change/remove a retention label once it’s been applied to content.
Sounds good in theory. 🙂
Background: In most cases, the retention label is auto-applied using a piece of metadata that is either set as default or manually applied by an end-user. This is a common design pattern I see where an end-user is required to set a mandatory document type they’re familiar with that will determine the retention label to be auto-applied. This post will not walk thru the steps to auto-apply a retention label – I have documented this in detail in another post of mine you can reference here: A Records Manager’s guide to Auto-applying Retention Labels using SharePoint IA.
Instead, this post is intended to share some important follow-on effects of taking the design approach of only using auto-apply retention labels on some/all of your sites without also publishing labels to those same sites. Although none of these effects may be showstoppers for you, you should understand them to ensure this is the approach that is right for your organization and to provide the appropriate guidance to end-users:
Effect 1: You won’t see the retention label dropdown in the item’s detail pane.
Effect 2: You won’t be able to unlock/lock a file when a record retention label has been auto-applied.
Effect 3: If your tenant level records management settings prevent users from deleting a retention labeled item, they won’t be able to un-label it to delete it.
The “Fix”: If needed, how you can make the retention label and unlock/lock UI controls appear.
Effect 1
“You won’t see the retention label dropdown in the item’s detail pane.”
If you are auto-applying either a standard or record retention label, there’s a UI effect. When the retention label is auto-applied to the content (image shown where the System Account has applied it) and the end-user opens up the information detail pane for a document in SharePoint, the Label property will not be shown. This is because no retention labels have been directly published to the site.
Is this a good thing? Some records managers would argue that the label can’t be removed nor changed so it’s a good thing.
The potential downside? If the condition changes (metadata for example) and/or a different retention label should be applied (either manually or automatically), no one can remove or change the retention label currently applied to the file thru the UI.
Effect 2
“You won’t be able to unlock/lock a file when a record retention label has been auto-applied.”
The unlock/lock toggle will not appear in the information detail pane for a document in SharePoint. If you have auto-applied a record retention label and you have the tenant-level records management setting set to ‘Enable record versioning’ (below), an end-user won’t be able to unlock/lock a file to edit the file and create a record version in the Preservation Hold Library.
In this scenario, if the record retention label was configured to start in an unlocked state (a setting on the label definition shown below), then end-users could certainly edit the file, but they wouldn’t be able to lock it when they were done editing it.
Alternatively, if you are starting a record retention label in the locked state (image below) and once applied to content, you don’t want an end-user to have the ability to unlock it, then this configuration will not be an issue and will work as designed.
Effect 3
“If your tenant level records management settings prevent users from deleting a retention labeled item, they won’t be able to un-label it to delete it.”
There is a tenant-level records management settings to allow/disallow users from deleting content that has a retention label applied. The setting in this image disallows it:
In this configuration, an end-user will see this message if they attempt to delete a labeled item:
If it is your desire to disallow it, but also provide an opportunity for an end-user to remove the retention label so the file can be deleted, then you will not be able to do this since the label dropdown does not appear in the information detail pane for them to remove it.
Alternatively, if you allow users to delete items (below), then the labeled file can be deleted and it will be preserved in the (hidden) Preservation Hold Library on the site.
The “Fix”
There are a few options, each with pros/cons.
Option 1: If at least 1 retention label is published to the site, then both the retention label dropdown and the unlock/lock toggle (for record retention labels) will appear without issue (image). You may want to consider publishing the same label you auto-applied; however, this is part of a larger design decision.
Option 2: Thanks to a blogpost reader, Tim, there is another way to remove a label without publishing one… if you select a file and choose More… Compliance details, you will be able to select the hyperlinked label that is applied to the file. If you select the label hyperlink, you can set it to None which removes the label. The Compliance details pane is a leftover popup from the classic SharePoint Records Management feature and, for that reason, I don’t like to rely on it for any of the modern retention controls. In this case however, it is a way to remove a retention label if you don’t want to publish one to the site. It is a lot of extra clicks, but it will work. Thanks Tim!
Option 3: Big thanks to my developer friend, Martin Lingstuyl, who developed an open source Microsoft 365 extension that, when deployed to a site, will show an additional option in the document context menu and list command bar called Retention controls:
When clicked, it will show a popup with the retention label information as well as providing the option to clear the label and toggle/untoggle the record (if it’s a record retention label):
This can be done on an individual document basis or in bulk. Check out Martin’s post for more details on his solution and how to install/deploy it: Extending Microsoft 365 with Custom Retention Controls
In the future, if the behavior changes such that the retention label UI controls show in the detail pane without publishing at least 1 label (Fix option 1), then I will delete this post. In the meantime, I hope you found this post helpful for your deployment strategy.
Parting thoughts…
I understand the desire for Records Managers wanting to remove the retention label decision from end-users; however, please understand the follow-on effects of this decision based on the combination of the records management tenant-level settings and the retention label configuration.
Thanks for reading.
-JCK
Hi Joanne,
We also exclusively use only auto-apply labels for our customers. Based on our experience as long as the user has edit permissions, they can remove a retention label on a record by going into to More->Compliance details then scrolling down to Label Status click on the retention label link for the label applied. This launches a new tab where the only selection is None. Then choose Save and the label will be removed. This allows records to be deleted or reclassified before the next run of the auto-apply service. You should be able to do this without publishing any labels. In addition, we use a script to remove labels in bilk as needed.
We also have the “allow users to delete items” options turned off, so we don’t end up with records that have a retention label that needs to be changed going to the preservation library and not being able to remove or reclassify the records without modifying the retention label itself and forcing expiration which impacts all other records using that same label. We ran into a scenario where a customer could not delete records that were mistakenly sent to the preservation library, so we don’t recommend having these settings turned on.
Also, we believe there are some good reasons not to use locking to edit records, the main one being every time a record is unlocked it creates a copy of that record in the preservation library that remains in-place for the duration of the retention period. If you need to undo or re-classify a record that copy in the preservation library will remain and show up in the disposition process creating invalid ghost records. The other reason is, we find users do not want to spend the time clicking to unlock a record, so we have versioning turned on and allow them to create new versions, while preserving the original record version. These seems to work fairly well.
Thanks for bringing these discussion points up we have spent lots of time navigating the impact of these options. Please let me know if you have any questions about what we did, thx, Tim.
Hi Tim! Thanks for your response!! A few comments… I generally never advise to go into the legacy “Compliance details” pane and so don’t typically suggest it as a workaround. That said, your suggestion is great and it is a way of removing the label without having to publish one. I didn’t know this was an option to remove the label! I have updated the post to include this as an option – thank you!
I don’t disagree with your commentary around options you prefer at the tenant level; however I work with customers that have done all combinations of these settings so the post is simply talking to the follow-on effects if you’ve chosen them.
I don’t understand your last paragraph where you say “we have versioning turned on and allow them to create new versions, while preserving the original record version.” When you say you have ‘versioning turned on”, I assume you’re not referring to “Record Versioning” at the tenant level as the first part of that same paragraph you talk about not liking it. Can you please elaborate.
Appreciate the discussion! 🙂
Hi Joanne, thanks for clarifying, I was hoping you weren’t indicating that the capability to remove the label using the method I outlined was going away, we currently depend on it. My comment on versioning is specific to SharePoint versioning. My understanding is, as long as a retention label is associated with the document, previous versions cannot be overwritten. Thx.
Thanks Tim – got it!
Hi Joanne,
How one can auto label SharePoint documents for 75 years retention from the time.. which should be based on the date of birth (metadata or property) from the SharePoint document ?
Prash
Genuine records compliance has to come from the organization, not the users. Put another way, retention labels are imposed by the organization on the user content, not the other way around. The very principle that end users arbitrarily decide retention for their content is the opposite of compliance. Therefore, it is absolutely imperative that the ability for end users to select retention must be removed. In this regard, Microsoft has records management “backward”, in that Purview has been configured to allow users to choose any retention they wish, and apply it to any document, for any reason. This is not compliance, this is non-compliance and must be avoided.
Bruce Miller
RIMtech Consulting