Microsoft is preparing a significant quality-of-life upgrade for Microsoft Purview Data Loss Prevention (DLP): administrators will be able to create rule-based instructions that automatically resolve predictable alerts and apply tags that make the remaining work easier to find, assign, and audit. The feature, listed as Microsoft 365 Roadmap ID 568371, is scheduled for Preview in August 2026 and General Availability in September 2026 for Microsoft Purview on the web in the worldwide standard multi-tenant cloud. Microsoft’s roadmap entry frames the capability around customer-defined business needs rather than a one-size-fits-all security response.
That distinction matters. DLP has always been strongest when it identifies potentially sensitive activity across Microsoft 365, but identifying activity is only the beginning of the operational problem. A compliance team also has to decide which alerts deserve investigation, which describe known and permitted business processes, which should be routed to an internal owner, and which can safely be closed without spending analyst time.
Alert auto-resolution and tagging rules aim to turn those recurring judgments into a durable part of the DLP operating model. Instead of asking analysts to manually close every low-risk event involving a trusted business process, organizations will be able to tell Purview in advance how to treat alerts that meet clearly defined conditions.
Microsoft Purview DLP policies can generate alerts when a policy-rule condition is matched, while the policy itself may be configured to monitor, warn, restrict, or otherwise protect sensitive data. Administrators investigate those alerts through Microsoft Purview and Microsoft Defender XDR, with Microsoft recommending Defender XDR for investigation and alert management while using Purview to create and edit the underlying DLP policies. Microsoft’s DLP alerts documentation describes that division of responsibilities.
The DLP alert surface is also wide. Purview’s alert dashboard covers policies enforced across:
The incoming feature is therefore not simply a convenience setting. It is an attempt to address the alert operations side of data protection. A DLP program that identifies every possible policy match but leaves analysts to manually sort repetitive, low-value cases can create its own form of risk. Backlogs obscure urgent events, inconsistent triage decisions weaken auditability, and analyst fatigue encourages overly broad policy changes that may reduce protection.
Microsoft’s roadmap description gives two practical examples:
For example, a sales representative sending customer information to an external address might be a concern. The same action may be routine if the recipient belongs to a contracted fulfillment partner, the transfer is covered by an approved data-processing agreement, and the message content meets the organization’s established sharing rules. Conversely, treating every partner domain as inherently safe would be dangerous if the domain is compromised, misconfigured, or used for an unapproved purpose.
Purview’s existing DLP controls already acknowledge that alert volume must be managed. Microsoft supports both single-event alerts, which are typically suited to high-sensitivity, lower-volume events, and aggregate-event alerts, which can identify patterns across a defined period. Microsoft’s documentation uses the example of a single email containing 10 or more customer credit-card numbers for a high-sensitivity event, compared with a threshold alert built from multiple lower-volume email events over 48 hours. Microsoft’s DLP alert configuration reference explains both alert types and their intended use cases.
Aggregation reduces duplicate reporting, but it does not solve the entire triage problem. An aggregated alert is still an alert that needs context. A large enterprise may have dozens of business exceptions that are legitimate in a narrow set of circumstances:
A well-designed DLP policy can still detect and act on a sensitive-data condition. The planned rule-based alert action would decide how to handle the alert record after it is created, based on pre-established customer logic. In principle, this preserves the security policy’s detection signal while preventing routine, understood cases from consuming manual triage capacity.
That difference could be important for audit and governance. Existing Purview DLP policy documentation notes that DLP alerts and events flow into the alerts dashboard and DLP Activity Explorer for authorized administrators, while policies can also be scoped through administrative units to limit which administrators see which policy results. Microsoft’s DLP policy reference details both unrestricted and administrative-unit-restricted policy administration.
The exact retention, audit representation, conditions, precedence rules, and reporting behavior for auto-resolved alerts have not been described in the public roadmap entry. Administrators should therefore avoid assuming that auto-resolution is equivalent to deletion, or that tagging will automatically alter all downstream workflows. Those are implementation details that Microsoft will need to document during Preview or closer to General Availability.
A label such as Business Process can communicate that an event is related to an established workflow rather than an unexplained data-transfer attempt. Similar organization-specific tags might identify:
Rule-based tags can add a layer of classification that is not necessarily present in the original DLP policy. A policy might be designed to detect a category of sensitive information across an entire tenant, but the appropriate response could differ dramatically based on business context.
Consider a DLP rule that detects financial account information being sent outside the organization. Without business-aware tags, every match may enter a common queue, even if some are known outbound deliveries to a contracted payroll provider and others involve unknown consumer mail providers. With meaningful tag rules, a team could potentially separate:
A “Business Process” tag, for instance, should mean that an alert met well-defined organizational conditions. It should not be attached simply because a user belongs to a department that often works with sensitive data. A Legal employee can still make an accidental disclosure. A trusted vendor domain can still be subject to account takeover. An approved process can still be used in an unapproved manner.
Organizations should retain the distinction between:
But the phrase “trusted partner domains” should invite caution. A domain allowlist can be useful, but it is not a complete trust decision. The organization must account for business changes, typosquatting, third-party compromise, recipient forwarding rules, and the possibility that a message is sent to an address at a legitimate domain but to the wrong individual.
A robust rule should therefore avoid simple logic such as “any message to
Examples could include:
There is a meaningful difference between that AI-assisted triage path and the roadmap’s planned rule-based auto-resolution and tagging:
This is not an either/or choice. A sensible deployment could use auto-resolution rules to keep known low-risk activity out of the frontline queue, tags to send specific workflow cases to the right people, and the Triage Agent to help analysts understand the alerts that remain.
The Triage Agent can also support remediation reminders for SharePoint and OneDrive alerts categorized as needing attention, using Microsoft Teams messages to the last user who modified the relevant file. Microsoft’s Purview Triage Agent guidance notes that this remediation capability is in Preview and relies on Teams app deployment settings. That workflow is complementary: auto-resolution removes cases that are already understood, while remediation focuses on outstanding issues that should be corrected.
The risk is that organizations may layer too much automation onto a weak DLP foundation. If the sensitive-information types are poorly tuned, exceptions are undocumented, and role assignments are overly broad, automation will make bad decisions faster. The right sequence is to improve policy quality first, then apply deterministic workflow rules to cases with a reliable history.
The goal is not to eliminate the highest-volume rule automatically. The goal is to identify high-confidence, low-risk, repetitive outcomes. A frequently generated alert may indicate a valuable policy signal, a misconfiguration, or a process that needs remediation—not necessarily a candidate for closure.
This phased approach is especially valuable for sensitive workflows involving external collaboration. It allows the organization to test whether the rule catches only the expected business process or whether it is broader than intended.
Only a small group should be able to create or alter auto-resolution criteria. The people who can define what is “safe to close” are effectively shaping the organization’s data-protection response. That deserves change control, peer review, and separation between business-request approval and technical implementation.
Useful success measures include:
First, it recognizes that alert queues are business systems, not merely technical logs. Security products often capture the event but leave organizations to build the workflow around it. Rule-based resolution and tagging bring more of that workflow into the DLP platform.
Second, deterministic rules are usually easier to explain than opaque automation. A compliance officer can understand a rule that says a specific alert category is tagged for Legal or resolved when it meets a narrow, documented trusted-partner condition. This can improve consistency across analysts and shifts.
Third, the feature should help make Microsoft 365 DLP more sustainable at scale. Purview can protect and alert across many services, but broad data coverage needs correspondingly mature handling processes. Reducing routine noise enables scarce compliance and security personnel to spend more time on events with real uncertainty or potential impact.
The risks are equally real.
The most obvious is false confidence. An auto-resolved alert might represent a known business process today but an unauthorized transfer tomorrow. Partner trust is not static, employee behavior changes, and a rule that is valid in one context can be misapplied in another.
Another risk is configuration sprawl. Organizations may accumulate dozens or hundreds of special-case rules that few people understand. A tagging taxonomy can become meaningless if every department requests a custom label and no central owner governs how it is used.
Finally, automation can unintentionally hide policy-quality problems. If a rule produces too many legitimate alerts, the organization might auto-resolve them instead of asking whether the DLP policy should be scoped more precisely, whether user notifications should be improved, or whether a business workflow should be redesigned.
A mature Microsoft Purview DLP program will use the feature to codify decisions that have already been examined by security, compliance, privacy, and business owners. It will reserve automatic resolution for narrow, low-severity, well-governed cases. It will use tags to expose ownership and business context. And it will preserve strong escalation paths for data transfers that are high-risk, unusual, large-scale, or simply unclear.
With Preview expected in August 2026 and General Availability targeted for September 2026, Roadmap ID 568371 could become an important operational addition to the Microsoft Purview DLP toolkit. The real value will not come from the number of alerts an organization closes automatically. It will come from the quality of the decisions it chooses to automate—and from the clearer attention it can give to the alerts that truly matter.
That distinction matters. DLP has always been strongest when it identifies potentially sensitive activity across Microsoft 365, but identifying activity is only the beginning of the operational problem. A compliance team also has to decide which alerts deserve investigation, which describe known and permitted business processes, which should be routed to an internal owner, and which can safely be closed without spending analyst time.
Alert auto-resolution and tagging rules aim to turn those recurring judgments into a durable part of the DLP operating model. Instead of asking analysts to manually close every low-risk event involving a trusted business process, organizations will be able to tell Purview in advance how to treat alerts that meet clearly defined conditions.
Overview: moving DLP alerting beyond detection
Microsoft Purview DLP policies can generate alerts when a policy-rule condition is matched, while the policy itself may be configured to monitor, warn, restrict, or otherwise protect sensitive data. Administrators investigate those alerts through Microsoft Purview and Microsoft Defender XDR, with Microsoft recommending Defender XDR for investigation and alert management while using Purview to create and edit the underlying DLP policies. Microsoft’s DLP alerts documentation describes that division of responsibilities.The DLP alert surface is also wide. Purview’s alert dashboard covers policies enforced across:
- Exchange email
- SharePoint Online
- OneDrive
- Teams chats and channel messages
- Endpoint devices
- On-premises repositories
- Fabric and Power BI
- Other supported Purview instances and workloads
The incoming feature is therefore not simply a convenience setting. It is an attempt to address the alert operations side of data protection. A DLP program that identifies every possible policy match but leaves analysts to manually sort repetitive, low-value cases can create its own form of risk. Backlogs obscure urgent events, inconsistent triage decisions weaken auditability, and analyst fatigue encourages overly broad policy changes that may reduce protection.
Microsoft’s roadmap description gives two practical examples:
- Auto-resolving alerts that security teams do not need to see, such as low-severity email alerts involving only trusted partner domains.
- Tagging alerts associated with a particular department or workflow, such as labeling Legal-related alerts as a “Business Process.”
Why alert volume is a DLP problem, not merely an analyst problem
DLP is inherently contextual. The same sensitive-information match can mean very different things depending on the identity of the user, the destination, the business unit, the collaboration relationship, the location of the content, and the type of action involved.For example, a sales representative sending customer information to an external address might be a concern. The same action may be routine if the recipient belongs to a contracted fulfillment partner, the transfer is covered by an approved data-processing agreement, and the message content meets the organization’s established sharing rules. Conversely, treating every partner domain as inherently safe would be dangerous if the domain is compromised, misconfigured, or used for an unapproved purpose.
Purview’s existing DLP controls already acknowledge that alert volume must be managed. Microsoft supports both single-event alerts, which are typically suited to high-sensitivity, lower-volume events, and aggregate-event alerts, which can identify patterns across a defined period. Microsoft’s documentation uses the example of a single email containing 10 or more customer credit-card numbers for a high-sensitivity event, compared with a threshold alert built from multiple lower-volume email events over 48 hours. Microsoft’s DLP alert configuration reference explains both alert types and their intended use cases.
Aggregation reduces duplicate reporting, but it does not solve the entire triage problem. An aggregated alert is still an alert that needs context. A large enterprise may have dozens of business exceptions that are legitimate in a narrow set of circumstances:
- A law firm receives privileged materials from a defined group of external counsel.
- A healthcare operation exchanges protected data with contracted providers.
- A manufacturer shares controlled specifications with a named logistics partner.
- A finance team transfers regulated reports to an approved external auditor.
- A legal department distributes litigation-hold materials through approved collaboration channels.
- A merger-and-acquisition team uses restricted data rooms and specialist advisors.
The difference between suppressing an alert and resolving it
The roadmap language specifically refers to resolving alerts that organizations do not need to see in the triage queue. That is operationally different from broadly disabling alert generation or weakening the DLP rule itself.A well-designed DLP policy can still detect and act on a sensitive-data condition. The planned rule-based alert action would decide how to handle the alert record after it is created, based on pre-established customer logic. In principle, this preserves the security policy’s detection signal while preventing routine, understood cases from consuming manual triage capacity.
That difference could be important for audit and governance. Existing Purview DLP policy documentation notes that DLP alerts and events flow into the alerts dashboard and DLP Activity Explorer for authorized administrators, while policies can also be scoped through administrative units to limit which administrators see which policy results. Microsoft’s DLP policy reference details both unrestricted and administrative-unit-restricted policy administration.
The exact retention, audit representation, conditions, precedence rules, and reporting behavior for auto-resolved alerts have not been described in the public roadmap entry. Administrators should therefore avoid assuming that auto-resolution is equivalent to deletion, or that tagging will automatically alter all downstream workflows. Those are implementation details that Microsoft will need to document during Preview or closer to General Availability.
What rule-based alert tagging could change
The tagging component may prove just as important as automatic closure. DLP teams frequently need to distinguish between alerts based on business meaning, not merely technical severity.A label such as Business Process can communicate that an event is related to an established workflow rather than an unexplained data-transfer attempt. Similar organization-specific tags might identify:
- Legal Review
- Approved Partner Exchange
- Human Resources Process
- Financial Reporting
- Vendor Onboarding
- M&A Restricted Workflow
- Possible Policy Tuning
- Escalate to Privacy
- Security Investigation Required
Better routing begins with better classification
An alert queue is only useful if people can quickly isolate the subset they own. Microsoft’s existing DLP Alerts dashboard supports filters, customizable columns, alert details, related events, and actions for assessing whether a policy match is a true match or a false positive. Microsoft’s dashboard documentation describes those investigation features, including the ability to examine the user, policy match, event context, and other details.Rule-based tags can add a layer of classification that is not necessarily present in the original DLP policy. A policy might be designed to detect a category of sensitive information across an entire tenant, but the appropriate response could differ dramatically based on business context.
Consider a DLP rule that detects financial account information being sent outside the organization. Without business-aware tags, every match may enter a common queue, even if some are known outbound deliveries to a contracted payroll provider and others involve unknown consumer mail providers. With meaningful tag rules, a team could potentially separate:
- Approved recurring activity that is auto-resolved but retained for reporting.
- Known business workflows that should be reviewed by a specialist team.
- Potentially risky activity that stays visible in the priority queue.
- Policy-quality candidates where a rule appears to be producing a recurring false positive.
- Confirmed security concerns that need rapid escalation through Defender XDR or incident-response processes.
Tags should not become substitutes for severity
There is an important governance caveat. A tag is useful for classification, ownership, and workflow, but it should not become an excuse to override risk without evidence.A “Business Process” tag, for instance, should mean that an alert met well-defined organizational conditions. It should not be attached simply because a user belongs to a department that often works with sensitive data. A Legal employee can still make an accidental disclosure. A trusted vendor domain can still be subject to account takeover. An approved process can still be used in an unapproved manner.
Organizations should retain the distinction between:
- DLP severity, which conveys the policy’s assessment of data-protection significance.
- Business-process classification, which explains the operational context.
- Alert disposition, which records how the event was handled.
- Incident status, which may be managed in a broader security workflow.
Auto-resolution can reduce noise—if the rules are narrow
The strongest use case in Microsoft’s announcement is the simplest one: a low-severity alert involving email sent only to trusted partner domains. If the relevant partner relationship is legitimate, defined, and monitored, auto-resolving those alerts could reduce substantial queue noise.But the phrase “trusted partner domains” should invite caution. A domain allowlist can be useful, but it is not a complete trust decision. The organization must account for business changes, typosquatting, third-party compromise, recipient forwarding rules, and the possibility that a message is sent to an address at a legitimate domain but to the wrong individual.
A robust rule should therefore avoid simple logic such as “any message to
partner.example is safe.” Instead, an organization should think in layered terms:- The DLP alert must be Low severity.
- The recipient must match a specific approved domain or identity group.
- The outbound data type must be within an approved category.
- The source user or group must be associated with the authorized business function.
- The transmission must occur through the expected Microsoft 365 workload.
- No higher-risk conditions, unusual volume signals, or contradictory policy matches should be present.
- The partner approval itself must have a named owner and a periodic review date.
The value of a “do not auto-resolve” list
Every auto-resolution strategy should include an explicit set of exceptions. Some data types and event patterns should almost never be automatically closed, regardless of an otherwise trusted destination.Examples could include:
- High-severity DLP events.
- Bulk data transfers over a defined volume threshold.
- Transfers involving privileged, regulated, or export-controlled information.
- Events from unusual devices, locations, or identities.
- A sudden spike in activity from a user or department.
- Events connected to an active insider-risk or security investigation.
- DLP matches involving a recently added or unreviewed external partner.
- Events where policy conditions indicate an attempted bypass or override.
Where this fits alongside Purview’s AI-assisted triage
Microsoft Purview has also been expanding its DLP Alert Triage Agent capabilities. The agent can run automatically on a Microsoft-managed schedule or be run manually, and organizations can choose a time range of alerts for it to triage. Microsoft’s Triage Agent documentation describes options ranging from only new alerts through the prior 30 days.There is a meaningful difference between that AI-assisted triage path and the roadmap’s planned rule-based auto-resolution and tagging:
| Capability | Core approach | Best suited to |
|---|---|---|
| Rule-based auto-resolution | Deterministic customer-defined logic | Repetitive, approved, low-risk cases |
| Rule-based alert tagging | Deterministic classification and routing | Departmental ownership and business workflow categorization |
| Alert Triage Agent | Automated analysis and risk-oriented triage | Investigating alerts that still require contextual interpretation |
| Human review | Expert decision-making | High-impact, ambiguous, novel, or sensitive cases |
The Triage Agent can also support remediation reminders for SharePoint and OneDrive alerts categorized as needing attention, using Microsoft Teams messages to the last user who modified the relevant file. Microsoft’s Purview Triage Agent guidance notes that this remediation capability is in Preview and relies on Teams app deployment settings. That workflow is complementary: auto-resolution removes cases that are already understood, while remediation focuses on outstanding issues that should be corrected.
The risk is that organizations may layer too much automation onto a weak DLP foundation. If the sensitive-information types are poorly tuned, exceptions are undocumented, and role assignments are overly broad, automation will make bad decisions faster. The right sequence is to improve policy quality first, then apply deterministic workflow rules to cases with a reliable history.
Deployment guidance for Microsoft 365 administrators
The roadmap places Preview availability in August 2026 and General Availability in September 2026. That makes the Preview period an opportunity to test operational design, not merely a chance to turn on a new switch.1. Baseline the current alert queue
Before creating any auto-resolution rules, measure the alert environment. Identify the policies generating the most alerts, the departments involved, the most frequent destinations, the analyst time spent per alert type, and the percentage of cases eventually treated as expected business activity.The goal is not to eliminate the highest-volume rule automatically. The goal is to identify high-confidence, low-risk, repetitive outcomes. A frequently generated alert may indicate a valuable policy signal, a misconfiguration, or a process that needs remediation—not necessarily a candidate for closure.
2. Document the business rationale
For every proposed auto-resolution rule, maintain a short decision record that defines:- The policy and alert conditions involved.
- Why the activity is accepted.
- The data types that may be included.
- The approved external domains, partners, or departments.
- The responsible business owner.
- The approval date and expiration or review date.
- Conditions that must prevent automatic resolution.
- The evidence that supports the risk decision.
3. Start with tags before closure
Where practical, implement tagging first. Tagging can reveal whether the proposed business logic is classifying the intended alerts without removing them from analyst visibility. Teams can inspect tagged cases, validate assumptions, and adjust criteria before enabling auto-resolution.This phased approach is especially valuable for sensitive workflows involving external collaboration. It allows the organization to test whether the rule catches only the expected business process or whether it is broader than intended.
4. Limit administration through least privilege
Purview’s role model matters here. Microsoft lists several roles that can view the DLP alert management dashboard or edit alert configuration, while dashboard access also requires the Manage alerts role plus applicable DLP compliance permissions. Microsoft’s role and permission guidance also makes clear that access to content preview and matched sensitive content requires additional content-viewer permissions.Only a small group should be able to create or alter auto-resolution criteria. The people who can define what is “safe to close” are effectively shaping the organization’s data-protection response. That deserves change control, peer review, and separation between business-request approval and technical implementation.
5. Monitor the impact after release
Microsoft notes that it can take up to three hours for alerts to be generated after an existing DLP alert configuration is changed. Microsoft’s DLP alert documentation While that timing refers to current alert configuration behavior rather than the new roadmap feature specifically, it reinforces a broader point: security teams should allow time for changes to take effect and should monitor outcomes over days or weeks, not minutes.Useful success measures include:
- Reduction in manually triaged low-value alerts.
- Percentage of auto-resolved alerts later found to require review.
- Volume of alerts by tag and business owner.
- Time-to-triage for high-severity alerts.
- Number of policies requiring rule adjustments.
- Number of active partner or business-process exceptions past their review date.
- Incidents involving activity that would have met an auto-resolution rule.
The main strengths and the operational risks
The planned Microsoft Purview DLP feature has several clear strengths.First, it recognizes that alert queues are business systems, not merely technical logs. Security products often capture the event but leave organizations to build the workflow around it. Rule-based resolution and tagging bring more of that workflow into the DLP platform.
Second, deterministic rules are usually easier to explain than opaque automation. A compliance officer can understand a rule that says a specific alert category is tagged for Legal or resolved when it meets a narrow, documented trusted-partner condition. This can improve consistency across analysts and shifts.
Third, the feature should help make Microsoft 365 DLP more sustainable at scale. Purview can protect and alert across many services, but broad data coverage needs correspondingly mature handling processes. Reducing routine noise enables scarce compliance and security personnel to spend more time on events with real uncertainty or potential impact.
The risks are equally real.
The most obvious is false confidence. An auto-resolved alert might represent a known business process today but an unauthorized transfer tomorrow. Partner trust is not static, employee behavior changes, and a rule that is valid in one context can be misapplied in another.
Another risk is configuration sprawl. Organizations may accumulate dozens or hundreds of special-case rules that few people understand. A tagging taxonomy can become meaningless if every department requests a custom label and no central owner governs how it is used.
Finally, automation can unintentionally hide policy-quality problems. If a rule produces too many legitimate alerts, the organization might auto-resolve them instead of asking whether the DLP policy should be scoped more precisely, whether user notifications should be improved, or whether a business workflow should be redesigned.
A more mature model for Microsoft Purview DLP operations
The best interpretation of Microsoft’s upcoming alert auto-resolution and tagging rules is not “make alerts disappear.” It is make alert handling intentional.A mature Microsoft Purview DLP program will use the feature to codify decisions that have already been examined by security, compliance, privacy, and business owners. It will reserve automatic resolution for narrow, low-severity, well-governed cases. It will use tags to expose ownership and business context. And it will preserve strong escalation paths for data transfers that are high-risk, unusual, large-scale, or simply unclear.
With Preview expected in August 2026 and General Availability targeted for September 2026, Roadmap ID 568371 could become an important operational addition to the Microsoft Purview DLP toolkit. The real value will not come from the number of alerts an organization closes automatically. It will come from the quality of the decisions it chooses to automate—and from the clearer attention it can give to the alerts that truly matter.