Microsoft Purview DLP + Power Automate: Automated Response to Policy Violations
A DLP policy that generates an alert you review tomorrow is not incident response — it is documentation. The gap between when a violation occurs and when a human acts on it is where data exposure lives. In regulated environments, that gap has a cost measured in compliance obligations, not just security risk.
Since early 2025, Microsoft Purview DLP supports a native integration with Power Automate: when a DLP rule fires, it can trigger a custom flow as part of the rule action. No polling. No SIEM middleware. No manual triage before the first notification goes out. The flow runs at the moment the violation is detected.
This article covers how to configure that integration — the DLP rule side, the Power Automate side, the licensing and permissions that must be in place, the supported locations, and three practical flow patterns you can adapt for your environment.
GCC/GCC High/DoD note: This article covers worldwide commercial tenants. The DLP → Power Automate integration for GCC/GCC High/DoD environments was postponed and not proceeded with at the time of writing — check your Message Center for updates. Verify availability in your tenant before building on this.
Supported locations: Exchange Online, SharePoint Online, OneDrive, and Windows devices (Windows 11 24H2 and above). For SharePoint and OneDrive, flows are triggered only for new or modified content. Verify the current supported locations in the official documentation — this list may expand.
Licensing: No additional Purview licence is required beyond your existing DLP subscription. The flow creator needs a Power Automate plan that allows premium connectors — the Microsoft Purview connector is premium. Verify the current licensing requirements at the official documentation before rollout.
Flow ownership and sharing: By default, a flow is only available to the user who created it. For a DLP-triggered flow to function in production, the flow creator must share it with the DLP policy owners or use a service account as the flow owner.
In this article
How the integration works
The integration has two components that must be configured independently and then linked together in the DLP rule.
🔍
DLP policy match
Content matches a sensitive information type or label condition in an active DLP rule
→
⚡
Rule action fires
"Start a Power Automate workflow" action configured in the DLP rule triggers the linked flow
→
🔗
Microsoft Purview connector
Power Automate receives violation metadata: user, file, policy name, matched SIT, location
→
🤖
Automated response
Notify manager, post to Teams channel, log to SharePoint list, create Planner task, restrict sharing
The flow is built first in Power Automate using the Microsoft Purview connector as the trigger. Once the flow is ready, it is linked to the DLP rule in the Purview portal — at the rule level, not the policy level. This means you can have different flows for different rules within the same policy, which matters if you have rules with different severity levels or different response requirements.
The DLP action does not replace the other rule actions — block, audit, notify user, generate alert. It runs in addition to them. A rule can simultaneously block the sharing attempt, notify the user via policy tip, generate a Purview alert, and trigger a Power Automate flow.
Use cases worth automating
Manual DLP alert triage scales poorly. These are the scenarios where automated response delivers the most immediate value:
Manager notification
Notify the user's manager at the moment of violation
Built-in policy tips notify the user, but managers are not automatically informed. A flow using Microsoft 365 Users and Outlook connectors can retrieve the manager and send a structured notification within seconds of the violation.
Security team escalation
Post high-severity violations to a Teams security channel
For violations matching your highest-severity rule (e.g. GDPR-scoped sensitive data shared externally), a flow can post a rich adaptive card to a dedicated SOC or security channel with violation metadata and a direct link to the Purview alert.
Incident logging
Create a structured incident record in SharePoint or Planner
Compliance teams need a traceable record of violations. A flow can create a SharePoint list item or a Planner task with the violation metadata — policy name, matched SIT, user, timestamp, file path — for every match, giving you an audit trail outside the 30-day Purview alert window.
Remediation
Restrict sharing links on the violating file
For SharePoint and OneDrive violations, a flow can call the SharePoint REST API or Graph API to remove sharing links or change the file's permissions immediately — turning a detection into a remediation without waiting for human intervention.
Prerequisites
1
Active DLP policy with at least one rule
The Power Automate action is configured at the rule level, not the policy level. You need at least one published DLP policy targeting a supported location (Exchange, SharePoint, or OneDrive). The policy can be in audit mode — the flow will still trigger on matches.
2
Power Automate plan with premium connector access for the flow creator
The Microsoft Purview connector is a premium connector. The flow creator needs a Power Automate plan that allows premium connectors. Verify the current licensing requirements in the official documentation before building the flow — plan inclusions and connector tiers can change.
3
DLP policy authoring permissions in Purview
The admin linking the flow to the DLP rule needs the standard DLP policy authoring role in the Microsoft Purview portal. No additional role is required for this specific capability. Power Automate roles are managed separately — the flow creator needs appropriate Power Automate permissions to create and share flows.
4
Flow shared with DLP policy owners
By default, a Power Automate flow is private to its creator. Before linking a flow to a DLP rule, share it with the admins who manage the DLP policy, or use a service account or managed identity as the flow owner. If the flow creator leaves the organisation, an unshared flow will stop working.
Build the flow in Power Automate
The flow must be created before it can be linked to a DLP rule. You can create it from the DLP rule authoring page directly, or build it independently in Power Automate and link it later.
Option A — From the DLP rule authoring page (recommended)
1
Open the DLP rule and add the Power Automate action
In the Microsoft Purview portal → Data loss prevention → Policies → [your policy] → Edit → Rules → [your rule] → Add an action → Start a Power Automate workflow.
2
Create a new flow or select an existing one
Choose Create a flow to open Power Automate with the Microsoft Purview connector pre-selected as the trigger, or choose an existing flow you already built. The DLP trigger in the Microsoft Purview connector is: "When a DLP policy is violated" (or the equivalent for your location).
3
Use the built-in template as a starting point
Microsoft provides a template: "Notify manager when a DLP policy is violated". It uses the Microsoft 365 Users connector to look up the violating user's manager and sends an email. This is a good baseline — extend it with Teams notifications, SharePoint logging, or remediation steps.
Option B — Build the flow independently in Power Automate
1
In Power Automate, create a new automated cloud flow
Go to make.powerautomate.com → Create → Automated cloud flow. Search for Microsoft Purview in the connector list. Select the trigger "When a DLP policy is violated for a SharePoint, OneDrive or Exchange item".
2
Add your response actions
The trigger passes violation metadata to subsequent actions as dynamic content: Matched policy name, Violating user email, File URL, Sensitive information type detected, Location, and others. Use this data to build contextual notifications and logs.
3
Save and share the flow
Save the flow, then go to the flow's detail page → Share → add the DLP policy admin as a co-owner. Return to the Purview portal, open the DLP rule, add the Power Automate action, and select this flow from the list.
Configure the DLP rule action
Once the flow exists and is shared, linking it to a DLP rule takes a few steps in the Purview portal. The configuration is at the rule level — if you have multiple rules in a policy with different severity levels, you can link different flows to each.
Test in audit mode first. Set your DLP rule to Audit mode before enabling the Power Automate action in enforcement mode. This lets you validate that the flow fires correctly, that the metadata is populated as expected, and that notifications reach the right recipients — without impacting users or generating real incidents.
1
Navigate to the rule in the Purview portal
Microsoft Purview portal → Data loss prevention → Policies → [policy] → Edit policy → Rules. Edit the specific rule where you want to add the automated response.
2
Add "Start a Power Automate workflow" as a rule action
Scroll to the Actions section of the rule. Select Add an action → Start a Power Automate workflow. A panel will open showing your available flows — select the flow you built and shared.
3
Save the rule and submit the policy for review
Save the rule. If the policy is in simulation or audit mode, save and leave it there for testing. When validated, switch the rule to Turn it on enforcement mode. The flow will now trigger on every match that hits this rule.
Three flow patterns to adapt
Pattern 1 — Manager notification with Teams escalation
The most common starting point. Notifies the violating user's manager by email and posts a summary to a Teams security channel for high-severity policies.
# Trigger: Microsoft Purview - When a DLP policy is violated
# Available dynamic content from trigger:
# ViolatingUserEmail, PolicyName, SensitiveInfoTypeDetected,
# FileURL, Location, RuleName, Timestamp
# Step 1: Get the violating user's manager
# Action: Microsoft 365 Users - Get manager (V2)
# Input: User (UPN) = [ViolatingUserEmail] from trigger dynamic content
# Step 2: Send manager notification email
# Action: Outlook - Send an email (V2)
# To: [Manager/Mail] from Step 1
# Subject: DLP Policy Violation - [PolicyName]
# Body: User [ViolatingUserEmail] triggered a DLP rule.
# Policy: [PolicyName]
# Rule: [RuleName]
# Sensitive type detected: [SensitiveInfoTypeDetected]
# File/location: [FileURL]
# Time: [Timestamp]
# Review in Purview: https://compliance.microsoft.com
# Step 3: Post to Teams security channel
# Action: Microsoft Teams - Post a message in a chat or channel
# Team: Security Operations (your team name)
# Channel: DLP Alerts (your channel name)
# Message: Adaptive card or plain text with same metadataPattern 2 — Incident log in SharePoint
Creates a structured record in a SharePoint list for every DLP match. Gives compliance teams a queryable audit trail that persists beyond the 30-day Purview alert window.
# Trigger: Microsoft Purview - When a DLP policy is violated
# Pre-requisite: Create a SharePoint list with these columns:
# Title (single line text)
# ViolatingUser (single line text)
# PolicyName (single line text)
# RuleName (single line text)
# SensitiveType (single line text)
# FileURL (hyperlink)
# Location (single line text)
# ViolationTimestamp (date/time)
# Status (choice: New / Under Review / Resolved)
# Step 1: Create item in SharePoint list
# Action: SharePoint - Create item
# Site: https://contoso.sharepoint.com/sites/Compliance
# List: DLP Incident Log
# Field mapping:
# Title = DLP Violation - [PolicyName] - [Timestamp]
# ViolatingUser = [ViolatingUserEmail]
# PolicyName = [PolicyName]
# RuleName = [RuleName]
# SensitiveType = [SensitiveInfoTypeDetected]
# FileURL = [FileURL]
# Location = [Location]
# ViolationTimestamp = [Timestamp]
# Status = New
# Step 2 (optional): Create Planner task for follow-up
# Action: Planner - Create a task
# Assign to: DLP admin or compliance officer
# Due date: +2 business days from triggerPattern 3 — Automated sharing restriction (SharePoint / OneDrive)
For high-severity violations on SharePoint or OneDrive files, the flow calls the SharePoint REST API via an HTTP action to remove sharing links from the violating file. This turns detection into immediate remediation.
Validate before enabling in enforcement mode. Automatically removing sharing links can interrupt legitimate business workflows. Run this pattern in audit mode for at least two weeks, review the matches, and confirm that the automated remediation action is appropriate for the specific rule's conditions before enabling it in production. Consider building in an approval step before the remediation action fires.
# Trigger: Microsoft Purview - When a DLP policy is violated
# Only suitable for SharePoint/OneDrive locations
# Step 1: Get file sharing links via Microsoft Graph
# Action: HTTP
# Method: GET
# URI: https://graph.microsoft.com/v1.0/sites/{siteId}/drives/{driveId}/items/{itemId}/permissions
# Authentication: Active Directory OAuth - use a registered app with Sites.ReadWrite.All
# Note: Extract siteId, driveId, itemId from [FileURL] dynamic content
# Use Parse JSON to extract sharing permission IDs from the response
# Step 2: Apply for each sharing link (loop)
# Action: Apply to each - loop over permissions from Step 1
# Condition: permission type is sharing link (not direct access)
# If true:
# Action: HTTP - DELETE
# URI: https://graph.microsoft.com/v1.0/sites/{siteId}/drives/{driveId}/items/{itemId}/permissions/{permId}
# Step 3: Notify the file owner that sharing was restricted
# Action: Outlook - Send an email
# To: [ViolatingUserEmail]
# Subject: File sharing restricted - DLP policy
# Body: Explain what was restricted and who to contact for review
# Recommended: Add an Approval step before Step 2
# Action: Approvals - Start and wait for an approval
# Approver: DLP admin or security team
# If approved: proceed with restriction
# If rejected: notify security team that manual review is neededLimits and caveats to document before you deploy
- Supported locations: Exchange Online, SharePoint Online, OneDrive, and Windows devices (Windows 11 24H2 and above) at the time of writing. Teams and other locations are not currently supported for the Power Automate trigger. Verify the current list before designing flows that depend on specific locations.
- SharePoint and OneDrive — new/modified content only: The flow only fires for content that is new or modified after the DLP rule is active. Existing items at rest that already violate the policy do not trigger the flow. Use DLP alert scanning and the Purview alert dashboard for retrospective coverage.
- Flow availability: The flow must be shared with the DLP policy admin account or owned by a service account. If the flow creator's account is disabled or leaves the organisation, the flow stops working. Plan for continuity at the time of deployment.
- Alert generation is separate: The Power Automate action does not replace the DLP alert. If you want alerts in the Purview portal or Defender XDR, configure alert generation separately in the same rule — both can run simultaneously.
- Audit mode still triggers flows: A rule set to audit mode will still fire the Power Automate action. This is useful for testing, but be aware that your flow's notification and logging actions will run on every match even when the rule is not enforcing.
- Connector preview status: The Microsoft 365 compliance connector reference is currently published as Preview. Validate connector behaviour in your tenant before production rollout — preview connectors can change without notice.
- Power Automate run history: Each flow run is visible in the Power Automate portal under the flow's run history. Use this to debug failed runs and verify that the trigger metadata is being populated correctly.
Deployment checklist
- Verify the DLP policy targets a supported locationThe Power Automate trigger currently supports Exchange Online, SharePoint Online, OneDrive, and Windows devices (24H2 and above). Confirm the policy includes at least one of these locations.
- Confirm the flow creator has Power Automate PremiumThe Microsoft Purview connector is premium. Verify the flow creator's licence covers premium connectors before building the flow.
- Build and test the flow in isolation before linking to DLPUse the flow's manual trigger or test mode to verify each action step — manager lookup, email, Teams post, SharePoint write — before connecting it to a live DLP rule.
- Share the flow with DLP policy owners or use a service accountPrevents the flow from breaking if the creator's account changes. Document the service account and its credentials in your key management process.
- Link the flow to the rule in audit mode firstRun the linked configuration in audit mode for at least one week. Review the flow's run history and the Purview alert dashboard to confirm matches are triggering the flow and that metadata is correct.
- Confirm alert generation is configured separately if neededThe Power Automate action does not generate a Purview alert. If you need alerts in the Purview dashboard or Defender XDR, configure the alert action in the same DLP rule alongside the Power Automate action.
- For remediation flows — add an approval step before enforcementAny flow that modifies permissions or restricts access should include a human approval step before executing. Automated remediation without approval gates can disrupt legitimate workflows.
- Document the flow owner and succession planRecord who owns the flow, what DLP rules it is linked to, and the process for transferring ownership. Review this when the flow owner changes role or leaves.
Get in touch
Need help designing your DLP response workflows?
Get in touch if you want help designing DLP policies, building Power Automate response flows, or integrating DLP alerts into your security operations process.
Official references
Sources