Many organisations have complex records retention requirements that are described in records retention schedules, disposal authorities or records authorities. For example:
- There may be different ‘levels’ of retention depending on the ‘state’ of a record. The final versions of certain records may have a longer retention requirement than the working versions.
- For each business function there may be multiple types of records, each with their own retention requirement or ‘class’.
- In some disposal authorities based on business functions, activities that produce records (for example ‘Meetings’) may appear in multiple functions with the same retention requirement.
This post describes multiple and different types of Microsoft 365 retention policies created with an E3 licence in the Information Governance section of the Compliance admin portal can be applied to a single SharePoint site.
Example retention schedules/disposal authorities
Most records retention schedules or disposal authorities list types (or ‘classes’) of records that are created or captured by the organisation, including through the completion of various activities or transactions, and define how long these records must be kept or retained by the organisation (or transferred to an archival institution).
These record types or classes are usually grouped, by business subject or function.
The following extract, from a private sector company records retention schedule, shows records grouped by subject type (‘Company records’).
In the example below, from the Victorian (Australia) government, records are grouped by function (‘Enquiries and Complaints’).
The diagram below presents a simple view of the examples above. For every subject type or business function, there may be one or more records description (based on the activity or transaction that creates or captures the record) with a corresponding retention period.
How does SharePoint manage records?
SharePoint Online team sites (including the sites linked with Microsoft 365 Groups and MS Teams) may be created to manage the records for a particular business area or function, or for a specific business activity.
Whether a single or multiple document libraries are used, SharePoint sites may contain a mix of record content. It may not always be possible to apply a single retention policy to the site.
Use case
For the purpose of this post, we will assume that the organisation has a business function named ‘Client Services’ – a generic name for a business unit that delivers client services.
The Client Services area has several SharePoint sites. One of these sites is named ‘Client Services’.
The ‘Client Services’ site, which has been active for several years, has multiple libraries for the activities it performs, including ‘Meetings’, ‘Procedures’, ‘Working papers’, ‘Rosters’, ‘Marketing’ and so on. Most of these libraries are created annually and consequently the year is added to the library name to help group content more efficiently – for example, ‘Meetings 2018’, ‘Meetings 2019’.
The organisation’s records retention authority has multiple classes for the Client Services function, including:
- Marketing – Retain for five years
- Meetings – Retain for seven years
- Procedures – Retain for seven years.
- Rosters – Retain for ten years
There is no class for general ‘working papers’ that may be created in support of the above activities, but the organisation would like to ensure that all content not otherwise covered by one of the ‘explicit’ retention policies above is retained by an ‘implicit’ or background policy.
Creating the Office 365 retention policy
Based on its requirements, the organisation will require two different options.
- A single retention policy with a minimum three year retention for content (including ‘working papers’) not covered by any other longer retention period. This will be created as an ‘implicit’ or background policy and applied to the site. Any content that is deleted by the end users will be moved to the invisible (to end users) Preservation Hold library. Records covered by this policy will be automatically deleted – via the Recycle Bin – at the end of the retention period.
- Multiple retention labels published in a single retention policy, that is applied on this site or other sites that can be mapped to the same function. This means that, when applied to a document library, every one of the labels will appear in the drop down menu in the library settings to apply a label. Depending on how the label has been configured, the records may be automatically deleted or subject to a disposition review.
Label-based retention policies – retention settings
Each retention label that is created will include a name and description, and then the label retention settings.
- How long it is to be kept (e.g., 7 years).
- What happens at the end of that period (delete automatically, disposition review, nothing).
- Trigger for disposal – date created, date modified, date labeled. The ‘Date labelled’ option is preferred as it will not prevent day-to-day actions on the library or make the synced version read-only.
This process is repeated for each label. Each label can include the ‘File Plan’ settings, for example any reference numbers, the Function and Activity, and so on.
Here are two of the labels that have been created:
Publishing the labels
After each label has been created, they can then be published together in a single (‘Client Services) retention policy that is applied to the site (Client Services).
The published policy now appears in the list of label-based retention policies. It also appears under the ‘Retention’ tab of the Information Governance section, along with all other published label-based policies and policies that are not based on policies.
Non-label retention policy
The ‘implicit’ or background policy is created directly as a retention policy, without the need for a label. This policy, named ‘Temporary records’, has a three-year retention. It is applied directly to the site (or multiple sites).
Applying the label-based policies to the site
The Client Services site has several libraries as shown below.
We want to apply the label-based policies to the libraries named ‘Meetings 2020’, ‘Rosters 2020’ and ‘Marketing’. The general ‘Documents’ library will be covered by the implicit retention policy for ‘Temporary records’.
To apply the label-based policies to the library, click on the library and navigate to Library Settings where the option to ‘Apply label to items in this list or library’ is found.
A drop down list shows all available label-based policies. As the ‘Client Services’ policy was only applied to this site, only those labels appear. Only one option can be selected for each library.
It is usually a good idea to check the box (hidden behind the list of policies in the screenshot below) to ensure that anything already stored in the library will be covered by the policy.
The Meetings 2020 library has now been assigned the Client Services Meetings – 7 years policy. As soon as this label as been applied:
- It will no longer be possible to delete any content.
- If the library has been synced to File Explorer, the library in File Explorer will become read only.
The only way to to remove this restriction is to remove the policy. Accordingly, it may be better to apply the label only when the library has become inactive.
Note – The Temporary records implicit policy will continue to operate in the background and will apply to any content in any library or list not covered by an explicit policy. Anything deleted will be moved to the Preservation Hold Library accessible only by the Site Collection Admins or higher.
The final model can be visualised as follows:
The longest retention option will always take precedence. So, if an explicit label-based policy has a retention period of 2 years, and the background implicit retention policy has a retention of 5 years, the content will be kept for 5 years.
Note also that only the content of the libraries or lists is deleted at the end of the retention period. The library or list – and the site – remain.
Conclusion
As described in this post, it is possible to create multiple retention policies and apply them only to a single SharePoint site.
This allow organisations to create targeted groups of retention policies which is likely to be useful in organisations with detailed or function/activity based retention schedules.
Planning is required to ensure that there is appropriate and effective retention coverage for all the content created and captured in all SharePoint sites.
Records about the world 
Hi Andrew – thanks for sharing.
Do you know any methods of implementing a library-level implicit retention?
The short answer – no. By this, I assume you mean a policy that cannot be seen or removed by end-users. I have been working with a group of others in the UK to see if we can get the ability to remove a policy by end users with edit rights removed.