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.

Scenario Description	Query
Apply label to all documents with the content type “invoice” that were last modified at least 1 week ago.	Contenttype:invoice AND Lastmodifiedtime<"last week"

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:

Scenario Description	Query
Apply label to all Meeting Documents where the meeting date was at least 1 month ago. The column “meeting date” has been mapped to RefinableDate12.	Contenttype:”Meeting Document” AND RefinableDate12<"last month"
Apply label to all Service Request files where the Request Response Date is before today. The column “Request Response Date” has been mapped to RefinableDate03.	Contenttype:”Service Request Document” AND RefinableDate03 < today

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:

Scenario Description	Query
Apply label to all policy documents where the adoption status is either “adopted” or “repealed.” The column “adoption status” has been mapped to RefinableString03.	Contenttype:policy AND RefinableString03:(adopted OR repealed)
Apply label to all procedure documents where the approval status is not “draft.” The column “approval status” has been mapped to RefinableString06.	Contenttype:procedure NOT RefinableString06:draft

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:

Scenario Description	Query
Apply label to all policy documents where the adoption status is either “adopted” or “repealed.” The column “adoption status” has been mapped to RefinableString03. If any policy document without one of these statuses has been in the site but not modified for over a month, label anyway.	Contenttype:policy AND (RefinableString03:(adopted OR repealed) OR LastModifiedTime<”last month”)

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!