Gravity Union

View Original

Auto-Label Policies in Microsoft Purview Records Management Part 2: Advanced Scenarios

This is Part 2 in our series of auto-labelling policies in Microsoft Purview Records Management with a discussion on configuring advanced retention scenarios. Read Part 1 for an introduction and overview of KQL.


Let’s continue with the examples of auto-labelling policies using KQL.

Case Examples: Advanced Scenarios

Delayed Classification

It is often preferable to delay retention labelling until documents have had a reasonable collaboration period for users to finish their work. For instance, this may be advisable if your retention label was configured to mark items as locked records.

To delay auto-labelling records, one strategy is to query based on the document’s last modified time. When using this property, make use of the reserved date interval keywords like “last week” and “this month” as shown in the example that follows.

See this content in the original post

Delayed Classification Using Custom Column Metadata

If the files have custom date metadata assigned to them, you can also map that column to a RefinableDate property and query against it in similar ways to the prior examples:

See this content in the original post

Labelling Based on a Status or Custom Text Field

For some records – like policies or procedures – you may want to delay labelling content as a record until the document has achieved a certain status, like “approved” or “submitted.”

To apply retention based on a status column or other text-based column value, ensure the following:

  • The SharePoint documents have a populated status or other text-based column associated with their content type: for policies, this might be an “adoption status” column.

  • The column you would like to query on these documents is mapped in the search schema against a RefinableString managed property

When ready, you can define your queries:

See this content in the original post

One Label, Multiple Triggers

If you label documents based only on a custom column or status field, there are risks that some records will go un-classified if the status is never updated or if it is misapplied. How do you ensure that all documents are eventually labelled even if a user forgets to update the status?

To prevent the non-classification of records, it is wise to layer a “just in case” condition that accounts for user error. For instance, you may have an auto-label policy that labels all accounts payable invoices once their status is “paid,” but what if an invoice has been missing this status for over a year? It can be safely presumed that this now-longstanding document is a record, and retention limits should be applied.

This example demonstrates one way to incorporate multiple trigger conditions in your query:

See this content in the original post

Additional Design Considerations for Auto-Label Queries

When crafting a KQL query as part of an auto-label retention policy, ensure that the query captures the following priorities:

1. The results should not have ANY overlap with other auto-label retention queries: retention labels will not overwrite each other if more than one query applies.

👉Keep in mind that at the end of label policy creation, you will also specify a scope (selected sites and locations) to run the query. Careful scoping helps avert potential overlap between multiple auto-label policies.

2. If the label is configured to mark content as a record, tailor your query to delay classification until a reasonable collaboration window has passed.

👉When the system labels documents as records, it imposes a toggleable lock on the content; this may frustrate end-users that are still collaborating and will negatively impact the solution’s adoption. To support delays, the query could specify LastModifiedTime<”this month” to only label records that were last modified at least 1 month ago.

Summary

Automated classification can be a boon for any organization managing their digital records, but sophisticated solutions merit careful planning. Designing an effective auto-label policy in Microsoft Purview Records Management asks for more than knowledge of KQL and the SharePoint search schema; it also requires planning around both your content’s compliance and collaboration needs to ensure the solution’s continued success. 

Reach out for support with implementing Microsoft Purview Records Management in your M365 environment – our experts would be happy to advise and chat!