In my previous post, I discussed that many feel Microsoft Purview does not support case management concepts and how I felt that it did. I encourage you to review this topic before continuing with this post. While I do feel Microsoft Purview is capable of case management concepts, I freely admit there are limitations to be considered. For review, these limitations include:
- 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 this post, I will address those limitations and provide insight to support case management in Microsoft Purview better.
Mitigations to Case Management Limitations
As indicated above, there are limitations to event-based retention as a solution for case management within Microsoft 365. Mitigations to consider would assist organizations in achieving the proper control necessary for records management in a case management system.
Starting the Closure Process When Primary Object Closed
In the previous post, I used the example of vehicle insurance where the customer defines the case. To continue in that vein, an organization would want to begin the content retention schedule when the customer account is closed. There is no way for Microsoft 365 to know this has happened to begin the retention countdown. But honestly, this is the case in any event-based retention today. Implementing any event, whether it is the account closing, an employee leaving, or even something as common as a fiscal year-end, is not something Microsoft 365 Purview can accomplish automatically out of the box.
Power Automate can resolve this. A Power Automate flow can monitor the location where the information for the customer’s account is stored. This could be Dynamics 365 or almost any other system an organization can use for this purpose. When the account is closed, the monitoring flow will be triggered, and a call can be made to Purview APIs to initiate an event on behalf of that closed account. From there, the process described for event-based retention can take over and dispose of the content based on their applied labels.
Individual Document Handling Can Be Very User-intensive
Unlike some systems, Microsoft Purview handles content disposal on a file-by-file basis. This means that if an account is closed, record managers or disposition approvers will not be provided with a group of documents based on a category for that account during the disposition process. This results in the approver having to go through each file individually if they wish to ensure they are ready to be disposed of. This will be a very user-intensive process.
There are a couple of options to handle this:
- Remove the need for a disposition review. If the account is closed and the content is no longer required based on the schedule, a disposition review may not be required. The retention label can be configured to dispose of the content once the schedule is reached automatically.
- Apply a meaningful timeline to allow for review of content and dispose of it automatically if not reviewed within that time frame. Recently (as of the writing of this post), Microsoft updated disposition congratulation options in Purview to automatically delete content if not handled manually by a reviewer. This feature won’t help with the grouping of content, but it will help control the disposition list getting too out of hand if content comes up for disposition in large groups all the time because of case closures.
Providing Additional Metadata for Disposition
A key limitation (in my opinion) of Purview and a significant problem for case management disposition is the lack of metadata provided to disposition reviewers in the disposition list. The lack of metadata means that disposition reviewers cannot group content by a particular case when reviewing the content. As mentioned, this is a general problem in Purview, but I want to flag it as a specific issue for case management because it really can hinder the efficient review of content during the disposition process of a case.
This lack of metadata does make sense because, by their nature and functionality, a retention policy spans the entire environment, not just a single location. Presenting custom metadata when it’s possible that no two documents in the disposition view at any given time could have the same metadata can be problematic. If Microsoft allowed all custom metadata to display for all content in the disposition review list, I could imagine that view getting very large.
Power Automate can assist here again. Microsoft has now added the capability to initiate a Power Automate workflow at the end of a retention schedule instead of using the Purview default process. Using Power Automate, a process can be developed to present a custom view of a label’s content up for disposition. Further, a process could be developed to allow the reviewer to use that same view to approve, extend, relabel, add a reviewer, or any other necessary process to the disposition flow.
In summary, utilizing Power Automate with event-based retention will allow many organizations to meet the needs they require for a case management record retention system. While Microsoft Purview won’t meet all of the needs of case management with out-of-the-box functionality, combining it with other resources such as the Power Platform will help greatly to bridge that gap.
Thanks for reading!