Previously, I showed you how to use Power Automate to build a custom workflow to assign approvers based on the site owner. It was designed to access the user(s) designated as site owners and assign the disposition approval to them. In addition, it allowed you to provide custom messages and any other non-standard activities your organization required. I will take a different approach in this post and assign record disposition based on document location. The idea is that labels are shared across the organization, and each site could belong to a particular data owner that does not map to the site ownership. The flow will target these data owners based on the document’s location. This first post highlights the components that need to be in place to support the flow. If you want to go straight to the flow components, continue to the second post in this series. However, I urge you to read on here first to understand what needs to be in place to support the solution as a whole. Before continuing, ensure you aren’t going to run into any of the Power Automate limitations within Purview.
Within SharePoint search, there are two key configuration components important to the ability to search for content. The first is called crawled properties. A crawled property is created for every site column that exists within SharePoint. This includes standard, out-of-the-box columns like Created By, Title, Name, etc. It also includes any custom site column created by users. However, a crawled property is not meant to be used as a field for direct searching by users, for filtering results, or for refining a search.
To make columns searchable, sortable, refinable, etc, the columns must be updated within the search schema of SharePoint. To allow users to actively use the columns in search refinement, custom queries, etc the columns need to be connected to the second key component of the search schema: the managed property.
An important concept to organizing data in SharePoint is to use metadata. Organizations are starting to see the benefit of moving away from a purely folder-based form of organization and are starting to embrace the use of metadata. Metadata as a method of describing your content is great for filtering, sorting, and even creating custom views to help you find your data quicker and more efficiently. In addition, having a strong metadata architecture for all of your content vastly assists organizations in adopting other key features such as records management, information protection, and now CoPilot. When you create metadata for particular types or categories of content, you should organize it into a content type to help ensure only the relevant metadata is gathered for a file or document. Content types exist at the library level, at the site level (for reuse in other libraries within the site), and at the tenant level in the content type gallery. Creating the content type at the gallery (previously known as the Content Type Hub) is important for additional capabilities like linking to the tenant search schema to aid in additional capabilities, such as locating data for Microsoft Purview features. This post will cover the process for the creation of content types in the content type gallery to further support Purview features such as records management, sensitivity labels, and other features found within Purview.
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.
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.