UPDATE (9 October 2019) – based on multiple requests, I will post examples describing ways to map complex retention schedules to Office 365 retention labels in the next post.
Records retention schedules, also known as disposal schedules or authorities, usually consist of multiple ‘classes’ of records that describe or define (a) a logical grouping of records (e.g., ‘financial records’) and (b) a period the defines how long those records must be kept after a ‘trigger event’ (e.g., ‘date created’ or ‘date last modified’) before they can be destroyed.
Records retention schedules/disposal authorities may can take multiple forms. They may:
- Be subject-based and describe specific types of records. For example, ‘financial records’, ‘client records’, ‘property records’.
- Map to the business functions and activities or file plan of the organisation, especially where records are grouped in this way. For example, ‘FINANCIAL MANAGEMENT – Accounting’ or ‘CLIENT MANAGEMENT – Cases’.
- Be ‘rolled up’ by disposal period. For example, all records with a 7 year retention period, regardless of the subject, business function/activity, or file plan. As we will see below, this method may be most suited for organisations with complex retention schedules that are deploying Office 365 retention policies.
This post describes how individual classes in these different forms of records retention schedules/disposal authorities can and, for the first two options above, will probably need to be mapped to Office 365 retention labels and policies.
Note – this post does not discuss the use of SharePoint site policies, which are used to apply a retention policy to an entire SharePoint site. This subject will be addressed in a separate post.
Office 365 Retention Labels and Policies
Somewhat confusingly, retention classes in Office 365 are created as ‘retention labels’ in the Classification section of the Office 365 Security and Compliance admin portal but are not active until they are published as retention policies.
Retention labels define types of records that can be covered by a single retention period. They can include any Business Classification or File Plan descriptors. The period of time that records are retained is based on one of: (a) date created, (b) date modified, or (c) date the label was applied. Disposal may result a ‘disposition review’ or the records may be destroyed automatically.
Retention labels must be published to become active. The publishing process includes a decision about the Office 365 locations where the retention label will be applied; the options are :
- All of Exchange email, SharePoint, OneDrive and Office 365 Groups.
- Any of the above, including specific mailboxes, SharePoint sites, OneDrive accounts, or Office 365 Groups.
It is essential to understand the way retention labels/policies will work in your environment as there is potential to conflict with other forms of retention. For example:
- End-user Exchange mailboxes are essentially a ‘personal’ storage location for emails (and attachments to emails) on a range of subjects. Many organisations retain Exchange mailboxes ‘as is’ for a period of time after the owner leaves the organisation. Until that time, there is no way to (a) consistently apply retention policies automatically or (b) enforce the folder structure of the inbox. Accordingly, it may not be practical to apply a retention policy to Exchange mailboxes. A long-held records management ‘requirement’ is to move business related emails to a document management system (EDMS), but unless this is automated it relies on the end-user.
- End-user OneDrive for Business (ODfB) accounts are similar to Exchange mailboxes in that they are the ‘personal’ storage location for documents on a range of subjects. The contents of these ODfB accounts are invisible to the organisation until the person leaves the organisation (although a Global Admin can access, if required). Consequently, organisations: (a) may try to encourage end-users to not keep the final version of work records in their ODfB accounts, (b) apply a standard retention policy to all ODfB accounts after the end-users leave. When this period expires, a delegated person (manager or IT) can access and review the contents.
- Office 365 Groups include Outlook conversations and MS Teams teams chat. This makes them somewhat similar to Exchange mailboxes. However, a key difference is that Office 365 Groups are emailed enabled; with careful thought, this means that instead of asking people to email an individual on a given subject, they could email the Office 365 Group, which would be a more efficient way to keep the records.
This effectively leaves SharePoint which is the primary storage location for records (including emails if they are copied) as the main location where retention labels/policies will be applied.
How retention labels/policies are applied in SharePoint
Once they have been published to SharePoint, and unless they are published to a specific site only, retention labels/policies become visible and available for use in every library and list across all SharePoint sites, via the Library or List Settings – ‘Apply a label to items in this library’.
As can be seen above, there is a single drop down list to choose from. A few observations are worth noting:
- Someone will need to apply the policy to the library. This will probably be either the Site Collection Administrators (usually IT but could include RM) or the Site Owner/s (usually the business unit). You cannot reasonably expect end-users to do this, or to do it consistently and accurately. Note that the auto-application of retention policies may be possible in some limited circumstances and with certain types of licences, but care needs to be taken when deploying these options.
- Once a retention policy is applied, nothing can be deleted from the library or list. This means that it may be better to apply a retention policy only when a library is inactive (because end users like to delete content in active libraries).
- The list of policies to choose from should not be too long, perhaps no more than 30.
- The text of each choice should be self explanatory and not ambiguous. Fortunately, any description added to the policy will appear when the cursor is hovered over the choice.
The third point above highlights a potential issue if there are complex or many records retention/disposal classes. There is probably no point in listing every single class that has the same 7 year retention period. Instead, it may be useful to create a ‘generic’ retention policy for records that all need to be kept for the same period of time (Company records – Retain for 7 years) and, if required, another for specific types of records that need to be identified separately but may have the same retention policy (Financial records – Retain for 7 years).
If your SharePoint site architecture maps generally to business functions (site names) and activities (library names), this can provide the context required to allow ‘mapping’ of records back to the original records retention schedule or disposal authority.
- For example, if your site name is ‘FinanceAP’ (display name ‘Finance – Accounts Payable’), and you have a library named ‘Invoices2019’ (display name ‘Invoices 2019’) it should be possible to apply a generic 7 year retention policy, mapping it back to the more specific class. If the records are to be subject to a disposition review at the end of the retention period, their context should be obvious.
As noted in a previous post, one of the weaknesses in the current Office 365 disposition review process is that records appear for disposal review as individual records. It is of course possible to group the records using filters in the disposition review window but, ideally, the records management team should use the disposition review alerts to then:
- access and review the complete original document library and, if the contents are ready for disposal;
- export the full set of metadata;
- delete the entire library (not just the individual records in it); then
- record this disposal action.
Organisations that have complex records retention schedules/disposal authorities should consider grouping retention classes that have the same retention period into a single generic policy, to avoid a very long ‘drop down’ selection option.
The site and library names (e.g., ‘https://tenantname.sharepoint.com/teams/FinanceAP/Invoices2019) should provide the necessary context to retention schedules/disposal authorities that are based on a Business Classification Scheme or File Plan. Note that, while business functions could be used for the site name, there may be a need for many more sites than functions. It may be useful to consider ‘sub functions’ that can be grouped under the primary function.
Office 365 records retention labels/policies should not be published to Exchange mailboxes or OneDrive for Business accounts because it is not practical to expect end-users to apply retention policies correctly or appropriately. Instead, these accounts should be subject to a single retention policy after the end-user leaves the organisation.