Microsoft Purview retention labels have four main triggers to start the retention period for content.  These triggers include the created date, the last modified date, and when the label was applied to the content.  The fourth trigger type fills in the gaps left by the previous three.  It is called event-based retention.  It helps organizations process retention based on other criteria such as fiscal or calendar year-end, contract expiry, project closure, etc.  It can also help support a record management concept known as case management, which I covered in a recent post and discussed with Joanne Klein in Episode #1 of Compliance Unplugged as a process that supports case management.  I thought elaborating further on event-based retention might be a good idea.  In this series, I’ll cover event-based retention capabilities, the back-end configurations necessary to get it to work properly, and how to execute the full process.

Event-Based Retention

There are two main components to consider for event-based retention:

  1. Event Type
    • The event type allows you to group a number of events under a single umbrella.  For example, you could have project-related content such as requirements, design, change requests, reports, etc.  You can support all of these documents and their unique schedules under a single event type.  This saves you from starting events for each and every document type.  Instead, you tie them into the event type and kick off an event based on that event type.  The system then reviews the labels connected to the event type and searches out the corresponding labels.
  2. Event Label
    • This is like any other label you create within the environment, but instead of selecting a date-based trigger or a label-based trigger, you can select a trigger based on the event type created.

Important: When planning your event labels, also ensure you plan for unique ways to identify your content for the event occurring.  Items such as an asset ID, project ID, employee ID, etc.  This ID is required to find all of the related items within the event type that the system needs to begin retention processing against.  If information is not provided to assist the environment in properly determining the required documents to begin the retention schedule against, then ALL documents within the event type will be affected.  With event-based labels, Microsoft makes the built-in field “Compliance Asset ID” (Called Asset ID in SharePoint) editable, but you may wish to create a custom field that makes more sense to your users.

Event-Based Retention Process

As indicated above, event-based retention covers instances where using the created or modified dates won’t work.  When an event occurs within the organization (employee termination, contract expiration, fiscal year-end, etc), the administrator will initiate an event within the tenant.  The event will target a specific event type or collection of event labels.  It will include a query that will assist the system in determining the correct content to search for and, once discovered, will begin the retention schedules for the required files.  The retention schedules are based on the label applied to the document, not the event type that was fired.

An advantage to this process is that you don’t have to target a specific classification of data (retention label) at a time to ensure the correct retention period is maintained for that file.  Nor does the event itself define the retention period.  The label that has been applied to the content still defines the retention schedule. The event simply begins the retention of that particular document.

Event-Based Retention Example

Let’s consider projects.  Every organization has a project of some sort at any given time and many retention schedules are based on project-related content.  The organization utilizes three types of documents in its projects:

  • Project Requirements – 5 years after project completion
  • Project Implementation – 10 years after project completion
  • Project Change Requests – 7 years after project completion

An event type called “Project Lifecycle” is created to facilitate this.  Once the event is created, three retention labels are created with the type of Project Lifecycle Event as the trigger.  Project sites are created as required, and every document within has a specific metadata field called ProjID to define it.  To give a bit of a visual representation, take a look at this diagram:

Event Based Retention - Project Setup Example

On January 31, 2023, Project 123 was completed.  The record manager will then create an event for the event type “Project Lifecycle”.  In the query, the record manager will indicate the project ID is Prj123.  They will then initiate the event.  Microsoft 365 then begins a search process to find all labels within the umbrella of Project Lifecycle, and within those labels, it will begin retention schedules for any content tagged with the value Prj123.  So the result looks like the following (red borders indicate documents that were flagged by the system):

Event Based Retention - Project Retention Event Example

It doesn’t matter where the data resides (other than within a Microsoft 365 storage location); the system only begins retention for the specified files.

Next, I’ll discuss the various configurations necessary for a successful deployment of event-based retention.

 

Thanks for reading!