Retention Methods

SharePoint Document Management: Retention Methods

In this article I want to avoid talking about the technicalities of how to set up Information Management and Retention Rules, but, want to explore the methods that can be used to enhance these processes within your Document Management System (DMS).

Document Retention allows for a SharePoint DMS to automate deletion or archiving of documentation after a defined amount of time. The rules that are defined may be simple through the use of the out-of-the-box features, or enhanced by introducing a SharePoint Designer Workflow.

Defining Retention Rules and processes in SharePoint is of great importance as it ensures an organisation is able to de-clutter and self-cleanse its documentation; usually something that does not occur within an on premise File Share due to its reliance on manual interaction from users, who frequently do not have the time to spend managing older documentation.

Organisations who wish to become or remain certified with ISO 9001:2015 also need to consider the implications of these strategies. Clause 7.5 covers Documented Information, with clause 7.5.3 specifically targeting the Control of Documented Information, with a point referencing “Its retention and disposition.”

So what methods should be considered when creating or improving your Document Management System in SharePoint? . . .

Retention Method 1

Method 1: Default rules per Library or Content Type

The first and most simplest route to consider is whether groups of documents or document types exist which all follow the same standard Retention Rule. As an example, all financial documents may only need to be kept for 7 years, no matter their contents.

If this scenario is true then the relevant Retention Rules can be defined on the Library by your SharePoint Development Team or Consultants, with the only reliance on your end user being that they upload the document into the correct location.

Rules can also be applied to a specific Content Type, to allow for more rules to take place in a single library. As an example, a Human Resources Library may have a general retention rule of 7 years, however, all CVs that are uploaded will only remain for 6 months. Setting rules against the Content Type allows for enhanced control of documents within a single location, but still does not rely too heavily on the end user.

This method would only require an end user to understand where a document is meant to live in SharePoint and what type of document they are uploading, to allow selection of the correct Content Type. There is no reliance on a user understanding the full Document and Information Retention Policy in your organisation.

Retention Method 2

Method 2: User selection of Retention Date

The second method is simple in its setup and use, but does have more reliance on an end users knowledge of the Document and Information Retention Policy.

This method defines that a user will select a piece of Metadata – “Retention Date” – that can be stored with the document. Retention Rules will then be triggered on this specific date. For example, a user may upload a document on 01/02/2018 and then set the Retention Date as the 01/02/2025 as they wish for it to last for 7 years. This date could also be increased or decreased over time if necessary, which does run the risk of users putting an extremely long date in place that goes against an organisations Retention Policy.

Majority of organisations will document their expectations around how long information can remain in the business before it is deleted or archived. I have seen documents in large companies that can be over 100 pages long due to the variety of data that is being managed. Therefore, this document would have to be made retrievable and usable for your end users to ensure they select the right period of time and then input the correct date.

This method is simple to implement, but does put a lot of pressure on the end user to make the correct decisions. This route may also be plagued with human error through the input of an incorrect date.

Retention Method 3

Method 3: User selection of Retention Time (automated Retention Date)

The third method is similar to requesting users to input the date, but instead requests that they just set the length of time and then let SharePoint manage the rest.

A new Metadata Column would need to be introduced, providing users with a choice of retention periods e.g. 6 months, 1 year, 2 years, 5 years, 7 years etc… An end user would be able to select this for every document they upload (pending this forms part of a Core Content Type) with a SharePoint Workflow generating the correct date to be inserted as another property. Please note that calculated fields can generate the correct date, but are not selectable when setting Retention Rules.

It is also advised that the choice field does not contain a selection of “50 years”, or “Keep Forever” as much like the word “Other” users will just select this by default each time, as they would all much rather keep their documentation and avoid selecting something that is too short.

This route provides less room for human error, as users are not expected to work out the date for themselves, and then type it in, with risk of them selecting an incorrect date. However, there is stil an expectant for them to understand the Retention Policy.

Retention Method 4

Method 4: Enhanced Metadata Driven Retention

The fourth and final method that I was to share is driven by an enhanced set of metadata. This relies upon your SharePoint Administrators or Consultants having a full understanding of Content Types and Inheritance to make this work correctly.

By enhanced metadata, I am referring to the use of multiple fields that can assist in defining the Retention Rule. This is of importance in organisations where a simple date or number of years is not applicable to the documents they own.

I have seen Social Care and Adoption documentation that relies upon “the service users date of birth plus 10 years” as their Retention Rule.

Documentation can also have multiple Retention Rules, such as; “a service users 18th birthday plus 7 years, or end of service users support (if under 18) plus 15 years.”

These rules cannot be managed through using Default Retention Rules (Method 1) as every individual document has its own rules to be followed. This can be managed, with great difficultly, through allowing users to input dates or select times (Method 2 and 3) as the user would need to fully understand what time has to be input and would need to continuously keep this updated. Therefore, my recommendation would be to take the time up front when developing the DMS and use additional metadata to handle this. As an example, a user can upload a document using the Content Type “Service User Document” which would then request the following;

–         “Service User Support Closure Date”

–         “Service User Date of Birth”

The Retention Rule that is used can then determine which path to follow, based on Metadata, and make correct decisions. Therefore, the only expectation on the end user is to fill in a set of properties that they should easily have the answers to.

To summarise, Retention Rules and Strategy is an extremely important factor in the creation of your SharePoint Document Management System. There are many different routes to choose depending on the rules defined by your either you organisation or the legislation it follows. The end user journey versus getting the correct retention results needs to be considered. Adhering to one or many of these methods will allow your business to run more efficiently, avoid any issues with data protection (specifically GDPR) and enhance your chances to become certified with Quality Standards.

Thinking about introducing Office 365 and SharePoint into your organisation for Document Management? Or already working with the solution with inefficient Retention Rules. Please reach out so that we can discuss this further. Would also like to hear peoples thoughts and experiences of Retention Rules and other methods that have assisted. 

This blog post was written by Steve Glasspool – Senior SharePoint Consultant at AMT Evolve.