Microsoft marks the feature as launched for general availability, including GCC, GCC High, and DoD environments, with an availability date of April 2025. The roadmap entry was updated on September 16, 2026, but that update date should not be mistaken for a new rollout: Microsoft’s own status and availability fields describe a feature that was already released.
For Purview administrators, the practical difference is straightforward. A domain-only event can establish that a user interacted with a service such as contoso.example, but it cannot distinguish the specific destination within that service. Showing the target path can help an analyst separate an upload to an approved workspace from activity directed at a personal area, a particular project site, or a service endpoint that shares the same host name.
Activity Explorer gets more useful evidence
Endpoint DLP exists to monitor and, where policy permits, prevent sensitive files from leaving Windows, macOS, and supported Windows Server devices through channels such as USB media, network shares, printing, restricted applications, browsers, and configured cloud-service domains. Microsoft’s Endpoint DLP documentation says audited endpoint activity is sent to Activity Explorer after devices are onboarded to Purview.
That telemetry already includes substantial context for certain events. Microsoft lists fields such as the activity type, device name, user, file name, file hashes, client IP address, source and destination location types, and—in the case of removable-media copies—the target file path. The Roadmap item narrows a conspicuous evidence gap for browser and cloud-service events: the destination had been represented only by a domain name.
The newly surfaced path does not change a DLP verdict. It does not make a blocked upload more blocked, expand the files Purview can classify, or turn an audit-only policy into enforcement. It improves the investigation record available after Purview has observed or acted on an event.
That is still a material operational improvement. Analysts commonly need to answer whether an alert represents an attempt to send data to an unsanctioned service, an accidental upload to the wrong area of an otherwise sanctioned service, or a legitimate business process that has been caught by an overly broad policy. A hostname alone can collapse those three situations into the same event.
Paths identify destinations; they do not expand policy matching
Administrators should not read the rollout as a new way to write highly granular URL-path allow or block rules. Microsoft’s Endpoint DLP configuration guidance remains explicit that service-domain settings use fully qualified domain names and that administrators should supply only the host name, without protocols or subsites.
Microsoft’s matching examples show why that distinction matters. A configured domain can match that domain and its subsites, while a wildcard entry can include the specified domain and its subdomains. In other words, policy scope is still established at the domain or subdomain level; the target path is additional evidence displayed after the activity occurs.
This leaves a deliberate limitation in place. An organization that allows a broad cloud-service hostname cannot use this Activity Explorer change alone to declare one URI path permitted and another prohibited. Purview may now reveal that difference to an investigator, but the documented Endpoint DLP service-domain controls do not become path-specific controls.
That boundary is especially important for teams reviewing uploads to large shared platforms. The evidence may show an event’s narrower destination, yet a policy design based solely on hostnames can still produce alerts for both expected and risky use of the same service. Administrators should therefore use the richer path information to tune policy scope, exception processes, and investigation workflows—not assume it substitutes for application-aware access controls.
The affected events are cloud-service upload investigations
Microsoft describes the relevant Endpoint DLP activity as “Upload to a restricted cloud service domain or access from an unallowed browser.” Depending on policy configuration, Purview can audit the attempt, block it, or block it while allowing a user to provide a justification and override the restriction.
The target-path improvement is most valuable where that activity generates a high volume of similar-looking events. An alert showing only a common domain may force the responder to collect browser history, proxy logs, secure web gateway telemetry, or an explanation from the user before deciding whether an escalation is warranted. A path in Activity Explorer can reduce that initial ambiguity.
It also matters for audit-only deployments. Many organizations begin Endpoint DLP in audit mode to map how sensitive files move before they impose blocking controls. Microsoft’s policy reference confirms that cloud service domain and browser activities can be configured for Audit only, Block with override, or Block. Better destination detail makes the audit phase more defensible: an administrator can review actual usage patterns rather than treating every event against a broad domain as equivalent.
There are limits to what Endpoint DLP observes. Microsoft documents browser-specific behavior for several controls and notes that browser paste monitoring applies to Microsoft Edge, Google Chrome with the Microsoft Purview extension, and Mozilla Firefox with that extension. Endpoint DLP also distinguishes file-upload activity from browser paste events: a service-domain list applies to file uploads, while pasting into a browser is governed separately.
A full target path should therefore be treated as one field in Purview’s endpoint evidence, not as a replacement for endpoint, browser, network, or SaaS audit logs. If an incident response process needs a complete transaction history—including authentication context, destination tenant ownership, download activity, or the eventual handling of the uploaded item—those details may still sit outside the DLP event.
Government-cloud availability removes a rollout split
Microsoft lists GCC, GCC High, and DoD alongside general availability for Roadmap 480734. That means U.S. government tenants were included in the stated scope rather than placed on an unspecified later schedule.
The inclusion is significant because Endpoint DLP investigations often intersect with highly controlled data handling, where the difference between an approved service location and an improper destination can matter as much as the destination domain itself. At the same time, Microsoft’s roadmap entry does not state whether the visual field, export schema, retention behavior, or APIs changed in lockstep across every cloud instance.
That omission matters to compliance teams that automate investigations or preserve DLP evidence outside the portal. The roadmap promises a display improvement in Activity Explorer; it does not promise a new programmatic field or revised export format. Organizations relying on SIEM ingestion, case-management tooling, or custom reporting should test whether the target path is available through their existing collection method rather than assume that a UI addition automatically flows downstream.
What Purview administrators should verify
The first task is to confirm that the relevant endpoints are actually reporting into Activity Explorer. Microsoft says that once a device is onboarded, audited activity can flow into Activity Explorer even before a DLP policy targeting devices is configured. For enforcement, however, both the device and the user must fall within the DLP policy’s scope.
Administrators should then create a controlled upload test using a file that matches a known sensitive information type or sensitivity-label rule. Review the resulting Endpoint DLP event and establish whether the target destination is displayed with enough path detail to distinguish the intended test location from another location hosted on the same domain.
A short validation run should include the following checks:
- Confirm that the event is a cloud-service upload or unallowed-browser activity, rather than a clipboard or unrelated file event with different metadata.
- Compare events involving the same domain but different destination paths to determine whether Activity Explorer exposes a meaningful distinction in the event-detail view.
- Verify whether the path is present in any export, alert pipeline, or SIEM workflow used for investigations, because Microsoft’s roadmap entry does not specify those integrations.
- Review service-domain entries separately, since the new display detail does not alter Purview’s documented hostname-based configuration model.
The change is a welcome fix to an evidentiary blind spot, but it should be understood at its proper scale. Purview now offers better destination context for Endpoint DLP investigations; it does not deliver path-level DLP policy enforcement. For teams deciding whether an upload alert is a policy failure, an approved exception, or a false positive, that distinction can save time—and prevent a generic domain name from driving the wrong response.