Over the past few months, the observant amongst you will have noticed the new ‘Records management’ section appear within Office 365’s Security & Compliance Center. This area collates some of the core EDRM functionality provided by Office 365 into a new shared space, providing a logical home for records management within Office 365, which I imagine will grow over time.
File plan
A file plan is an Information Governance term for a document (or series of documents) that details the types of records stored and (hopefully) managed by an organisation. For example, it defines how long different records need to be retained for, what triggers the start of their retention period and what happens at the end of the of their lifecycle.
At its core, the new ‘File plan’ feature within the Security & Compliance Center provides a central management hub for retention labels. It introduces the concept of ‘File Plan Descriptors’ which effectively allow you to group and classify your retention labels.
File Plan Descriptors are optional tags that you can choose to add to your retention labels. There are currently five Descriptors provided within Office 365:
Reference Id: a unique Id for the label. Duplicate values cannot be entered. From my testing there doesn’t seem to be any character limitations – you have significant flexibility to create your own Id patterns.
Business function/department – allows you to associate a label with a given part of your organisation. By default, Microsoft has provided a number of common department names for you to select from, including Marketing and Operations, although, I’d imagine that most organisations will add their own structure of functions and department names.
Category – provides a very flexible descriptor that enables you to tag your retention labels with a meaningful descriptor. Like Business function, Microsoft has provided some generic categories such as ‘Planning’ and ‘Administration’ which might reflect activity within your organisation.
Authority type – my assumption, based upon the pre-defined values (‘Business’, ‘Legal’ and ‘Regulatory’) is that this descriptor allows organisations to define a purpose for each of their retention labels.
Provision/citation – allowing you to define a series of regulations and legislation that are applicable to your organisation. This descriptor provides the ability to categorise labels by the regulation they are intended to help you comply with. Provision/citation descriptors are constructed out of three elements:
Name – the name of the regulation/legislation
Jurisdiction – the name of the organisation who has defined the regulation/legislation
Link – a link to the details of the regulation/legislation
The first thing that jumped out at me when I was experimenting with the File Plan, was how I currently can’t find a way to remove the out of the box descriptors. There absolutely has to be a facility to manage File Plan Descriptors, but so far, I’ve not been able to discover it. I’m fairly sure that it must be about to emerge via a future functional update, but for now, it looks like we might be stuck with the out of the box descriptors.
The next thing that I started thinking about, is what the descriptors provide. In their current state, they merely give us the ability to categorise our retention labels – something that I can see offering huge value for anyone with large file plans. However, in my experience, even the largest of organisations have started moving away from large file plans to much more pragmatic implementations.
One of the most revealing comments can be found at the top of the ‘File plan descriptors’ tab of the add/edit label page: “Based on the conditions you set below, we’ll automatically apply this label to content”. I can’t see this detailed anywhere, certainly it’s not mentioned in the official documentation, but I have to assume that within months the higher licence tiers of Office 365 are likely to see machine learning application of retention labels based upon the way the labels have been categorised. I can’t wait to see how this works in practice, however, for now I consider File Plan Descriptors the indication of future functionality that is around the corner – something I’d prefer to watch evolve before using at the heart of my architecture.
The other function provided by File Plan is the ability to export your labels (complete with their File plan descriptors) into Excel, to make them easier to analyse. You can also choose to import the file plan back from Excel, however, given that most of the properties of a retention label that is in use can’t be amended, I’d imagine that this functionality will be used more to support label reviews than for modification.
Events
Event-driven retention has been around for a while now but has now been rehoused within the new Records Management section. It provides us with a way of automatically triggering the start of retention based upon an event.
It’s not difficult to envisage scenarios where event-driven retention is a useful tool, for example being able to trigger the start of a retention period when an employee leaves the company or when a contract expires could be invaluable.
To use Event driven retention, you first need to create an ‘Event Type’ – for example we could use ‘Project End’ as an event type which we can trigger whenever a project is closed. We can then create our retention labels as normal, making sure that we choose to start retention of content based upon ‘an event’, selecting our event type ‘Project End’:
The other essential component is to ensure that we can identify which project different content belongs to. This effectively means that we need to ensure that we have a separate metadata column added to all of our projects, to allow us to find content belonging to a given project (and as you can imagine, if our event type is related to an employee leaving, we’d need to have metadata on content identifying the member of staff). In my example, I’m ensuring that all of my project content is tagged with the project name, ‘Project Alpha’ – something that’s much easier to achieve with pragmatic use of default values.
When a project is closed, retention can be started on the project’s content, by creating an Event that is associated with the Event Type. In my example, I can close my ‘Project Alpha’, by creating a ‘Project Alpha End’ event, which is associated with the Event Type ‘Project End’. This event can find the content that is associated with the project, by using an Asset ID – which is effectively our project metadata reference.
Of course, there’s nothing stopping you from automatically triggering the event, for example from another system. So, say when an opportunity is closed in your CRM, you could automatically apply retention to content relating to that opportunity. Event-based retention is a little fiddly to set up but can be a great basis for a dynamic records management solution.
Disposition
At the end of a retention period, some content can be automatically deleted, while other files need to be reviewed so that an informed decision can be made about how they are handled. The Disposition feature, which provides this function within Office 365 has also been recently moved into the new Record Management section of the Security & Compliance Center.
Disposition requires an E5 licence to access and shows both content that is currently awaiting disposition review, and also files that have recently been reviewed and are pending deletion.
Microsoft has invested heavily into the Disposition functionality, for example providing the ability the export a summary of items pending disposition to a .csv file. From a governance perspective, there are a few additional disposition features that I’m hoping to see introduced, especially the ability to export/send files to an archive, permanent automated defensible disposition features and also the ability to make review decisions over bulk content aggregations (e.g. decide what happens to all of a project’s content in a single review).