Thumbnail Implications of applying Purview retention labels to folders

Implications of applying Purview retention labels to folders

Microsoft 365 Purview allows you to create and publish retention labels that you can apply to data in SharePoint, OneDrive, Teams and Exchange. These labels ensure that data is retained for a required period of time. They define if content should be locked as a record in the meantime and if it should be deleted after the retention period has ended. This is especially useful for data that is not actively used, but still needs to be kept for legal or compliance reasons. In this blog post series I dive a little deeper into how to programmatically manage Purview retention labels and apply them to SharePoint content.

When you apply a retention label to a folder in a SharePoint library, it will automatically apply the retention label to all existing files in that folder. And it is also applied to files you add later. The same flies when using Document Sets. This is a very powerful feature, but it’s important to note that the folder itself is not subject to retention. Only the files are. The retention label only acts as a default label.

Important: A folder itself is not subject to retention. Only the files are. The retention label only acts as a default label.

This has all kinds of implications that you need to be aware of. Let’s take a look at some of them.

That’s right. This occurs when using a retention label that will delete content after the retention period ends. Because the folder itself is not under retention, Purview will not delete it after the retention term has ended. This may not be a problem for you, or it might, depending on the information structure of your site and if you are still working with folders a lot. Purview is essentially not the cleanup crew, but the compliance crew, and there’s a huge difference. So if you depend on Purview to clean up your sites, you need to be aware of this and you may need some kind of extra mechanism to delete empty folders.

Note: Purview is not the cleanup crew, but the compliance crew, and there's a huge difference.

This is a similar implication as the previous. If your retention label is supposed to relabel content after the retention period is ended, it will not do so for folders. It will only relabel files. This may be less of a problem than the previous one, but it can be confusing if you are not aware of it.

Document Sets are a special kind of folder. They are folders with a content type that allows you to add metadata to the folder itself. You can also share metadata between the files and the Document Set. This can be extremely useful for SharePoint environments functioning as a Document Management System. The Document Set and its files are often perceived as a unit, and it would make sense if it would be discarded as a unit after the retention term is over. As we have seen though, that is not the case. A folder is not subject to retention.

But this has an extra implication: say you have labelled a Document Set with a record-type label. You’d expect the metadata of the unit to be frozen. But it isn’t. The metadata of the Document Set can still be changed.

What’s more: shared metadata will no longer be shared… The values on the document set will now differ from the values that you see on the files in the Document Set. This is because the files are locked and the document set isn’t. It’s logical if you remember that folders are not subject to retention, but it is not what you’d expect as a business user.

Imagine the confusion that may arise from all this!

Note: Document set metadata can always be modified and is no longer shared with files labeled with record-type labels.

The above behavior about sharing metadata can be circumvented when you have enable a tenant setting for editing record properties. (Thanks to Joanne Klein for pointing this out!) Of course, that would need to fit in your information architecture, meaning that in many Document Management Systems, this would not be an option, because the metadata is as important as the file contents. But it’s an option you can consider and you can find it in the Purview portal global settings page:


Another implication of applying labels to folders is that users are still able to apply a different label to files in the folder. This may not be a problem, it may be the flexibility you like. The flexibility that comes with default labels. But it’s all about expectations. It’s not exactly consistent in a compliance setup where you’d like to be as consistent as possible. It’s important to remember that folder labels are ‘just default labels’, and nothing more.

Note: It's important to remember that folder labels are 'just default labels', and nothing more.

Once you have applied a default retention label to a folder, you may choose to change that label after all. This however, does not always change the label of the existing files in the folder. If the retention label you applied is a record-type label, the files will be locked as records. Updating or clearing the label of the folder has no effect on the labels of the files in that scenario. You’ll need to update or clear the label of the files separately.

If you have changed one of the files to a different label, after having applied a default retention label, this file will not be updated to the new label of the folder. It will remain the label you have applied to it individually, even if that is not a record-type label.

Event-based retention labels are a bit different. The retention term needs to be kickstarted manually, using a retention event. And there is an extra piece of metadata required: the Compliance Asset Id. I’ve explained about that subject in part 2 of this series. Now imagine you have labelled a Document Set with an event-based label. (For example a folder with files on a specific employee) As soon as you have done that, the Compliance Asset Id field will become visible:


Filling that field is important, as it will be used by a Purview to find labelled content. And here it starts getting interesting: while you can set a default label that will be applied to all files in a folder, you cannot set a default Compliance Asset Id. You would need to apply the label to each file individually as well.

Now say you’ve done that and asked someone with the appropriate role in Purview to kickstart the retention event on a specific date. Or maybe automation has done so for you, fantastic!

Now imagine someone going back to that directory some weeks later and adding a couple of new files. What happens is the following: Those files will now have the retention label applied. But they won’t have a Compliance Asset Id, and even if they had, the previous event has already been processed. So the new files will not be subject to the retention term. They will be retained indefinitely if nothing is done!

To fix that you would need to add a Compliance Asset Id to the new files and approach your Purview admin again to kickstart an event. In a manual scenario, this would be OK, although it would be something that could easily be forgotten. In a scenario where you have automation in place to label content, it could be a problem though. You would need to build extra automation to make sure that any new files are also updated with a Compliance Asset Id and processed using an event.

Note: As mentioned by Kuljeet Singh in the comments below, retention events do need a piece of metadata to find content, but it need not be the Compliance Asset Id that Microsoft provides. You can also kickstart events based on some other piece of metadata like a project number column field. It doesn't change the general idea here though: even if you're not using the Asset ID field, you'll still need to trigger a new event for any added files. Thanks for mentioning it Kuljeet!

Another one that I just though of: Disposition reviews. The idea of deciding what to do with content after the retention period is over is a great one. But it might also give some logistic issues when disposing of large quantities of data. It would be much quicker if you could have a single review for the entire folder. But unfortunately, that is not how it works. Remember, a folder is not subject to retention. And so, disposition reviews will be requested on file-level, causing a lot of separate items in Purview and a lot of work for reviewers.

I hope this article has helped you understand the implications of applying a retention label to a folder. If you have any questions or comments, please let me know in the comments below. And if you want to know more about Purview, check out my other articles on the subject.

purview retention sharepoint
Support me by sharing this


More blogs

Automating Purview data retention using Azure Functions
Automating Purview data retention using Azure Functions

An example of how to automatically apply Purview retention labels using Azure Functions.

Read more
Finding (and fixing) incorrectly applied Purview retention labels
Finding (and fixing) incorrectly applied Purview retention labels

In this blog post I will show you how you can find incorrectly applied retention labels.

Read more
Working with Purview event-based retention using code
Working with Purview event-based retention using code

Do you want to retain data for a period of time after a certain event has happened? It is called event-based retention and this is how you use it from code.

Read more


Thanks for reading

Thanks for reading my blog, I hope you got what you came for. Blogs of others have been super important during my work. This site is me returning the favor. If you read anything you do not understand because I failed to clarify it enough, please drop me a post using my socials or the contact form.

Warm regards,

Microsoft MVP | Microsoft 365 Architect

Microsoft MVP horizontal