When working with clients to plan and implement their records management strategy, a common concept comes up.  This subject is case management.  The reason this comes up often is that Microsoft 365 tends to handle content on a document-by-document basis.  Case management does not work this way, and as such, it is believed that Microsoft 365 Purview records management is incapable of supporting organizations that base most of their content on the case management methodology.  I feel that you can support case management with Microsoft Purview to a point, and the remainder can be handled by customization and or policy modifications.

What is Case Management?

Before we dig into how Purview can support case management, let’s first describe what case management is.  It’s not a concept that all organizations utilize, so some reading this post may not be aware of the concept behind the methodology.  Rather than focusing on content as an individual file or document, case management operates on content as a package.  The case (or package) of content is a collection of information, including different document types, processes, reports, communications, etc.  It is often connected to a person or group (organization, committee, etc.).  The information that makes up the case must be available for the case’s lifetime as the case itself defines the lifecycle of all supporting information.  In addition to the case controlling the status of the supporting content, because the content affiliated with a case can be of various types, you will end up with multiple retention timelines within a case at any given time.

Let’s consider the following example.  Your organization provides vehicle insurance to customers.  When a new customer is onboarded to your organization to purchase insurance coverage for their vehicles, you will create a new account for them.  This is your case.  The account or file directly affiliated with your new customer is the defining case in this situation.  Now your customer has two vehicles to be covered by the insurance policy.  The policy itself is one type of document, but the information about the vehicles themselves is an entirely different type of document.  However, the policy (or policies), vehicles, and the customer themselves are all tied together within the case.  Over time the relationship with the customer grows, and there is correspondence to track updates and change requests to the policies may occur.  New vehicles may be added and old ones removed.  Content related to the removed vehicles must be retained along with the case because it is part of that case’s history.  All of the files, forms, reports, and correspondence within the case have different retention activities attached to them, but they are all still tied to the case itself.  When the customer is removed from active status (the reason doesn’t matter), the case can be closed based on your organization’s rules (perhaps a case must remain open for a year after the customer is no longer active).  The case closure allows for all related content to be “free” for removal, but based on each type’s retention schedule.  Perhaps policy documents must be maintained for ten years after a closed case, but correspondence with the customer only requires three-year retention.

Case Management in Microsoft 365

Many consider Microsoft 365 incapable of handling case management-based retention.  This is untrue.  I feel a possible explanation for the misconception is due to the naming convention Microsoft uses.  The Purview feature that meets most case-management requirements is event-based retention.  In Purview, Microsoft named the feature Event-based retention instead of case management because the capability isn’t just about case management.  Event-based retention can also be used to trigger retention processes on content based on many different categories of criteria.  The events can range from fiscal or calendar year end to employee offboarding to customer closures and everything in between.  However, an event-based retention process can also support case management.  I provided an overview of event-based retention previously.

How Event-Based Retention Supports Case Management

Like case management, event-based retention also supports the concept of grouping content together.  Event-based retention groups related retention labels under event types.  In the example above, the organization can have retention labels for “customer documents”, “vehicle policy”, “policy change request”, etc.  Event-based retention allows record managers to group the content under an umbrella event type such as “Customer Insurance Lifecycle”.  Like case management, the content within the “Customer Insurance Lifecycle” does not begin its retention until the customer account is closed.

Closing the Case

Using event-based retention, record managers can also close the case in a manner required by case management.  A case and the content that is part of the case are closed when the primary object is closed.  In our example, the case would be closed when the customer is deactivated or closed based on the required criteria of the business.  Within Purview, this would occur by initiating an event for the event type.  Once the event has been initiated all content connected to the event type will begin their retention countdown (based on each label’s retention period) and eventually be disposed of.

Limitations of Event-Based Retention as a Method of Case Management

  • There is no OOTB method for starting the closure when the primary object is closed.
  • It can be user-interaction intensive
  • Disposition occurs document by document (not a group of documents related to the case\event)
  • When reviewing content up for disposition, there isn’t a way to know if the event-based content is part of a closed case due to a lack of metadata in the disposition view

In my next post, I’ll discuss mitigations to cover these limitations.

Thanks for reading!