A Tale of Two Retention Policies in Microsoft 365

There are two ways to create retention policies in Microsoft 365 – (a) by creating a label and publishing it as retention policy, or (b) creating a retention policy without a label. Both are created from the Information Governance section of the Compliance portal in Microsoft 365.

This post describes how the policies are created and applied, and the outcome for each.

Retention policy based on a label

Retention labels are created from the Labels tab of the Information Governance section in the Compliance portal.

Ideally, the name of the label would be based on a disposal class in a records retention schedule or records disposal authority. For the purpose of this post, the new label was named ‘Test One – Retain five years then delete‘.

Adding the details of the retention provided a quick visual clue to the retention details.

The label was configured to have a retention period of 5 years after the date modified after which the content could be deleted, with no disposition review. No record would be kept of what was deleted.

Alternatively, it would be possible to select the Disposition Review option. This option sends an alert to the account indicated so the records could be reviewed before disposal. However, keep in mind that if the trigger is left as ‘Date created’ or ‘Date modified’, records will be ready for disposition review based on those dates. It might be better to choose ‘Date applied’ instead so that a group of records could be reviewed at the same time – for example, in a SharePoint library.

Retention labels have no life unless they are published. This is achieved from the ‘Publish labels’ option in the same tab.

One or more labels can be published in a retention policy. This could be useful if the records disposal authority contained multiple labels for a single function.

As part of the publishing process, a decision has to be made to apply the policy to somewhere in Microsoft 365. In this case, the decision was made to apply it to a single SharePoint site because that site contained records that mapped to the retention label.

Finally, the new policy was given a name. In this case the policy had only one label so the policy had the same name as the label.

If the organisation’s records disposal authority/retention schedule had multiple retention classes mapped to a business function, the policy could be named after the function and include all the relevant classes created as labels.

All of these labels would appear in the drop down list from the Library Settings on every site where the policy was applied.

But even when it was published in this way and applied to a specific SharePoint site, the label does not do anything. The policy has to be applied to a document library in that site – but even then it wouldn’t do anything until the label was selected from a drop down list.

The screenshot below shows how the specific label is selected on the library and whether it should be applied to all existing items.

The label can now be seen in the ‘Retention Label’ column (when made visible in the view settings).

Anyone who uses the library to add and edit content (site members) will notice an obvious change if they try to delete anything, including from their synced document libraries in File Explorer.

They can’t.

There is, however, a workaround that end-users can use to delete documents with a label: (a) check the box next to the document, (b) open the information panel and (c) remove the label on individual documents.

Once the label is removed it no longer appears against the record.

The document can now be deleted. It will move to the Recycle Bin, from where it could be restored for up to 93 days if a mistake was made.

The lessons to be learned from this are that:

• It might be useful to make the library read only after the label is applied.
• The label should only be applied when the library became inactive, to allow people to get on with their work while it is still active.

If anyone was concerned about content being deleted from an active library, they could set an alert on the library.

In the meantime, for all the other records that retained their label, when the retention period ended the records in the library would be transferred to the Recycle Bin where they would sit for 93 days before complete and permanent deletion.

If no-one restored a document from the Recycle Bin, the content would be deleted, permanently, forever, without any record. The records managers might need to make a copy of the metadata for the documents to be deleted before they are deleted.

Alternatively, if they had selected the option for a ‘disposition review’ when the label was created, this would alert the records managers (and others) of the need to review the contents of the library.

Once everything had been deleted, all that will be left will be an empty library with no record of what used to be there.

Retention policy without a label

Non-label retention policies are created from the ‘Retention’ tab of the Information Governance portal.

For the purpose of this post, this label will be named ‘Label Two – Retain 5 years then destroy’.

This policy has the same retention period, trigger, and action as Label One – 5 years after date modified – and then the content could be deleted without any record of this being kept. [Note – yes the screenshot below shows 7 years].

As the policy was being created it was applied directly to a SharePoint site.

The policy could start working immediately.

Nobody, apart from the person who created and applied it knew it had been applied. It didn’t appear anywhere on the SharePoint site where it had been applied.

But, as part of the application process, it created a Preservation Hold (PH) library visible only to Admins, including the Site Collection Admins but not the Site Owners.

(Note – if end-users are allowed to create SharePoint sites, or Teams in MS Teams that also creates a SharePoint site, they are made Site Collection Admins by default and can accordingly see the Preservation Hold Library).

Anything that was deleted in advance of the retention policy expiry would be moved to the Preservation Hold library.

The PH library had a specific purpose – to ensure that everything on the site was retained until the end of the retention period.

It was not possible to restore any items from the Preservation Hold library. It was also not possible to ‘clear’ that library. If an administrator tried, they would be advised that ‘something went wrong’.

The only way to delete from the Preservation Hold library would be to remove the policy.

However, if a record was deleted it would be placed in the Recycle Bin for up to 93 days, from where it could be restored. If a record was restored in this way (from the Recycle Bin), the copy in the Preservation Hold library would remain.

For most people this type of policy was fine. They could (appear to) delete records, unaware that nothing was actually deleted if it were subject to a retention policy.

The same thing happened if a similar type of retention policy was applied to OneDrive accounts. End-users could ‘delete’, but nothing was actually deleted as long as the retention policy was active.

At the end of the retention period, the content that was subject to this policy was transferred to the Recycle Bin where it remained for 93 days. It would then be deleted, permanently, forever, without any record.

All that was left would be an empty library with no record of its previous content. The only clue would be in the ID or the ID part of the Document ID (if enabled). If anything new was added to the library, the next number in sequence would indicate how many records had previously been saved to that library.

Lessons to be learned

There are several lessons to be learned.

The first is that you need a plan to create and apply retention labels or retention policies to content across Microsoft 365. The configuration options and implications of each option need to be understood before they are applied.

You need to understand the difference between (a) a retention label published as a policy and applied to a SharePoint site and then a library on that site, and (b) a retention policy applied to an entire SharePoint site.

Retention labels can be mapped to retention schedule/disposal authority classes and then applied to specific libraries on SharePoint sites where the policy is applied. Accordingly, it may be useful to create document libraries that map to those classes, and only store content in those libraries that is covered by a single retention class.

If single SharePoint document libraries are used to store content that maps to different retention classes, then it will become very complicated to accurately map retention labels to content.

In many cases, it may be possible to apply a single non-label retention policy to a single SharePoint site or sites. For example, all project sites might have the same 7 year retention applied to all the content on the site as there may be no real need to apply policies to individual libraries.

Whatever you do, have a plan to act, document your settings, and keep it up to date.

And understand what happens at the end of the retention period. There is no back up.

What to use when – metadata, content types, folders or document sets

Most end-users will be familiar with using folders to ‘categorise’ content in SharePoint document libraries, but not everyone will be familiar with other options including document sets or the use of metadata or content types to achieve similar ‘grouping’ outcomes.

Any (and all of) these options can be used to categorise content in a document library. But, aside from the default folder option, some thought should be given to the actual purpose and the end-user experience for the other three options.

This post provides some suggestions for what to use when.

In summary:

• Use folders most of the time, but try to limit them (through end-user communication) to no more than two levels. Any more and it may be better to create a new library.
• Use document sets where there is a (genuine) need to group documents with additional metadata and security controls. In some cases, metadata may be a better option.
• Use content types (including document sets) sparingly and for specific business requirements, not just to categorise document types in a single library when a metadata choice, naming conventions, or separate libraries may provide a better outcome.
• Use metadata columns when it makes sense to display content grouped and filtered by that metadata.

Document libraries are logical aggregations for records

As a starting point, keep in mind that SharePoint document libraries are logical aggregations or ‘containers’ for records.

When a SharePoint site is mapped to a business function, the libraries in that site can be mapped to or named after the activities that produce records.

It is generally not a good idea, from a recordkeeping point of view, to mix records created by different business activities (which is not uncommon in the default ‘Documents’ SharePoint library, especially the site attached to a Team in MS Teams).

Access controls and records retention are much harder to manage in single libraries that contain records created from multiple different business activities.

As the library is the logical container, any option use to categorize or break up content in a library – whether it be metadata, content types, folders or documents sets – is similar to a divider in a lever-arch folder. Ideally, the entire content of the document library should contain records about the same subject.

Metadata

Content in a document library can be categorized using metadata.

SharePoint sites have more or less unlimited metadata that can be applied to content in document libraries. All document libraries include the default ‘Name’ and ‘Title’ metadata fields as well as system generated metadata.

SharePoint also includes the Managed Metadata Service (MMS) that allows for the creation of a centralised set of hierarchical metadata terms, based on taxonomies and thesauri, accessible to all sites.

Microsoft announced in April 2020 that it was modernizing the SharePoint Managed Metadata Service (MMS) and that the updates ‘will be essential to delivering new premium value to Project Cortex later this year’ (2020).

To add metadata to a document library, it must be either (a) added via a content type that contains one or more site columns, or (b) created as a ‘local’ library column. Both of these options can link to the MMS.

Once the metadata has been added, documents may be grouped in a view by the metadata. In the example below, they are grouped by the choice metadata column ‘Document Type’.

The benefits with using metadata include:

• Ability to draw on the global terms defined in the MMS.
• Ability to group and filter content, especially useful in libraries with a lot of content. Note that certain columns, including those that use MMS terms, cannot be grouped.
• Supports multiple pre-defined views that can replace search (especially useful since ‘faceted’ searching was deprecated).
• Support for recordkeeping requirements.
• Support for search.

The negatives with using metadata relate to usability and syncing.

• End-users generally don’t like to add more than two items of metadata when they upload a document.
• End-users generally don’t ‘get’ categorization or grouping by metadata (but generally they don’t seem to mind pre-defined views).
• Metadata columns are not visible in libraries that are synced to File Explorer.
• If a metadata column is mandatory, the synced library will become read only.
• Global metadata defined in the MMS may not suit all parts of the business. We found that even a simple set of terms to define ‘Document Type’ (e.g., ‘Meetings’, ‘Agenda’) varied across the organisation.

Suggested use case:

• Use metadata columns to categorise records (and the MMS) only when it meets a specific business need, not by default. For example, a document library for organisational policies that lists each policy (or group of policies and procedures) via the ‘Policy Name’ metadata field. The metadata can be used to describe the policies and related documents, categorize them in multiple ways. End users are unlikely to need to sync this library. This method also assists with cross-referencing related policies including by using links.

Content Types

Content types are a fundamental building block in SharePoint, and are used to define content.

SharePoint has long included the concept of a ‘Content Type Hub’ where, in theory, all Content Types are centralised. This will be replaced in the near future with the new ‘Content Types Gallery’ option accessible from the SharePoint Admin portal.

All content types derive from the top level ‘System’ content type that is used to define the ‘Item’ content type which in turn defines the ‘Document’ content type.

Every SharePoint document library includes (a) the default ‘Document’ content type with two metadata columns ‘Title’ and ‘Name’ and (b) the default ‘Folder’ content type. They also include the ‘Document Set’ content type when this is enabled as a site feature.

New content types are created from the Site Settings area of every SharePoint site but must be added to a library by first allowing content types (from Library Settings – Advanced) and then adding them from ‘Existing Site Content Types’. This process includes document sets which are discussed below.

Given their direct relationship with metadata, there may be a tendency to want to create a lot of content types whenever additional metadata is required and to apply multiple custom content types to a single document library to define a type of content when other options, such as a metadata choice or even folders, may work better.

In the screenshot below, the library column shows the Content Type for the particular object. This column can be grouped in a view, providing a way to show different content types in the library.

The benefits with using content types are as follows:

• Help to define content through the use of metadata.
• May include a template document which can use the metadata applied to the item. For example, automatically adding the metadata in the body of a Word document as a content control.

The negatives with using content types are as follows:

• There can be too many content types.
• End users don’t like having to choose a content type, especially if the only apparent purpose is to define a document type (e.g., ‘Meetings’ vs ‘Agenda’). In this case, a simple metadata column would be sufficient OR use document naming conventions instead.
• End users don’t like adding metadata after having to choose a content type.
• If any column in the content type is mandatory, it will cause the synced library to become read-only.

Suggested use case:

• A document library that is used to support a specific business purpose where it is necessary to define one or more documents using additional metadata, and a pre-defined document template is required. For example, a document library used to store client agreements based on a template. For each client agreement, there is a requirement to capture certain metadata (client name, address, phone, etc) which will then be auto-populated into the template agreement document.

Document Sets

Document sets are a like a super folder in that they behave like normal folders but have a lot more functionality.

As noted above, document sets must be enabled as a feature before they become visible in the list of available content types. Once enabled, and the option to ‘Allow management of content types’ is enabled in the Library Settings (under ‘Advanced’), they can be added to a document library from the list of available content types.

Document sets can be very useful where there is a need for (a) a unique identifier for a folder inside a library, (b) additional metadata to help define a group of documents and (c) access controls that may be different from the library. (Note – this last option is also possible with folders, see below).

While document sets may sound appealing to business areas that want to ‘hard categorize’ content in a document library (for example, every document set contains a policy, and related procedures, forms and so on), this can actually result in making it harder for end-users to find information. The reverse of this is that they can be very useful if there is a genuine requirement to restrict access to information.

Document sets are visible in the screenshot above regarding content types. When added to a document library, they are visible from the ‘New’ menu as shown below:

The positives of document sets include the following:

• They can have a unique ID (based on the Document ID being enabled in the library); the Document ID is the same used for the documents.
• Metadata can be added automatically to the body of template documents (via content controls) stored in document content types linked with the document set.
• They can be used to restrict access.

The negatives of document sets include the following:

• Can make it harder to find information, especially if there are more than around 30 in a library.
• Searches may retrieve only one document. It will also not retrieve the document set. There may be other related documents.
• Can be more difficult to replace with other options because of the relationship between document sets and linked document content types.
• In synced file libraries, document sets appear as folders. For this reason it is recommended that any library using document sets includes at least one mandatory column to make the synced version read-only. Ideally, end-users should not need to sync these libraries.

Suggested use cases:

• Document sets are a good way to group client-related or employee documents in a single library, especially when there is a need to restrict access between the document sets. In this sense, document sets work like ‘sub-files’ in a library. For example, Manager ‘Jim’ may need to see five document sets, while Manager ‘Mary’ may need to see eight others. Neither will be able to see the others files when they access the library.
• In smaller organisations, a SharePoint site might include a library called ‘Projects’, with one document set per project. Larger organisations might have a library per project, even larger organisations might have a single SharePoint site (perhaps based on a Microsoft 365 Group) per project.

Folders

Pretty much everyone knows what folders are and how they are used. Every SharePoint document library includes the option to create folders. When synced to File Explorer, end users can create folders there too.

It is possible to prevent the creation of folders in SharePoint via the Library Settings – Advanced – Folders option but this option should really only be enforced in exceptional circumstances.

It is also possible to view all the content in a library without folders by editing the view (or creating a new ‘No folders’ view) and changing the option in the ‘Folders’ section from ‘Display items in folders’ to ‘Show all items without folders’. It is not uncommon to find, when the no-folder view is displayed, to see fewer documents than folders. It is sometimes a good way for admins to demonstrate the benefit of using metadata columns instead.

The positives of using folders include the following:

• Everyone knows how to use them.
• They can be created from File Explorer.

The negatives of using folders including the following:

• Too many folders and levels.
• Folders that repeat other previous words in the URL path, including the name of the site and the library.
• One word folders – for example: Meetings – 2020 – June – 8.
• Folders with unique permissions.

Suggested use case:

• Folders are best for simple document libraries. It is a good idea to let end users know about the 400 character limit and suggest they might consider creating new libraries if the folders are clearly about entirely different subjects (unless this is very low level). For example, don’t mix records about meetings with records about policies or staff rosters all in the same library.
• Note: Try to avoid using unique permissions on folders. If unique permissions are really required, create a separate library.

Using all four (or a mix of the four) options

It is possible to use all four options in the same library:

• Folders
• Additional metadata colums, which may be used to group content in views without folders
• Added content types, including document sets with added metadata.

But it’s probably not a good idea to do this.

Keep it simple

If you are trying to categorise records in a way that makes some sense, it is not a bad idea to keep it simple and only deploy the option or options that best meets the business needs.

• Folders are best for most end users interacting with a library including via File Explorer. Limit the use of extra metadata – for example ‘Document Type’, keeping in mind that added metadata is not (yet) visible in libraries synced to File Explorer.
• Use metadata to create read-only views of records or other content stored in a library (for example, policies), and a small group of people is responsible for that metadata. Using metadata to group content in this way can be better than using folders or document sets. Keep in mind that not all columns (including MMS columns) can be grouped in views but they can be filtered.
• Use custom content types including document sets in situations where there is a need to add specific metadata to records (and use it in templates), or group them in ‘sub-files’ in a document library. Folders can be used in document sets to categorise content further.