I was building an ordinary custom DLP policy. Template, name, admin units, next, next. Then the locations page loaded and something at the bottom of the list did not belong there.

Dropbox. Salesforce. Google Workspace. And an entry called Feld, which took me a moment.

None of this is secret. There is a message center post, there is documentation, there is a roadmap ID. But a wizard tells you what a product actually thinks it is, and this one has quietly changed its mind about what DLP covers.

Until now, protecting a third party app meant switching on a location called Instances and then drilling into the app behind it. It worked. It was also abstract enough that most tenants never used it, not because anyone decided against it, but because nobody found it. Features that live behind a container get used by the people who read release notes. Features that appear in the wizard get used by everyone else.

Two footnotes on that list before we go further. The documentation currently confirms four supported apps for DLP, while the message center item MC1449180 names seven and adds ServiceNow, AWS and Cisco Webex. Rollout is phased per tenant, so your own wizard is the only reliable source. And auto labeling for these apps is narrower again, currently Google Workspace and Box only.

Microsoft is retiring the Instances policy location on 6 January 2027. After that date no new policies can be created against it, and existing Instances based policies are no longer supported. Instances relies on Defender for Cloud Apps file policy infrastructure for enforcement. The dedicated locations move that enforcement into Purview’s own model, which is exactly why both cannot survive.

So this is not four new checkboxes. It is a replacement path with a deadline, and right now the old and the new sit in the same list.

Count the concepts in that screenshot. Instances. Managed cloud apps, greyed out in my tenant. And the four dedicated locations. Three overlapping ways of thinking about non Microsoft coverage, on one page, in one wizard. That is what a platform mid migration looks like, and it is a good reason to document which construct your policies actually use before the retirement date asks you the question.

Now compare that screenshot with Exhibit A. When Dropbox is scoped, the Microsoft 365 workloads no longer carry editable scopes. When the classic workloads are scoped, the third party locations sit unselected. The wizard is enforcing a documented rule in the interface: non Microsoft app locations combine with each other, never with Exchange, SharePoint, OneDrive, Fabric or Devices in the same policy.

Which means a second family of policies. Plan the naming convention and the ownership before you create the first one, not after the twelfth.

The condition list is the screenshot I would show anyone who still thinks DLP means finding a credit card number and blocking the mail. It mixes several very different signal families.

The two I would build first are the least glamorous ones: document could not be scanned and document was not fully scanned. Given that encrypted files and PDFs are not classified in these apps today, those conditions are the difference between knowing where your blind spot is and quietly assuming you do not have one.

Two honest caveats. That list is short, roughly twelve conditions against the very long catalogue you know from Exchange or SharePoint policies. And one entry reads „content from Microsoft 365 is shared“, which is a strange thing to find in a Dropbox policy and a good hint that this condition set was adapted rather than purpose built. Test what each condition evaluates in your target app before you rely on it. Attribute availability also differs per app: created date, for example, is not available in Dropbox.

It enforces, and it alerts

The action set includes restricting access and encrypting content, so this is not a reporting exercise. And the rule carries a severity for admin warnings plus an alert on rule match, which lands in the same DLP alerts dashboard as everything else. Activity Explorer covers these policies too. Content Explorer does not.

The wizard states it plainly: pay as you go billing must be configured to create policies for non Microsoft 365 data sources. Purview runs two complementary models. Per user licensing covers Microsoft 365 and Windows or macOS endpoints and is unchanged. Pay as you go is consumption based, requires the tenant to be linked to an active Azure subscription, and requires an explicit consent step. Without that consent, the feature is simply not available to you.

For this capability the meter is Purview At Rest Protection, and the unit of measure for at rest files in non Microsoft apps is 1,000 files equal one data asset. Check the current price per asset on the Purview pricing page before you quote anything. The shape matters more than the number: your bill scales with the volume of files you bring into scope, not with the users you licensed. A broad „protect everything in Box“ policy and a narrow policy on two high risk instances produce very different invoices for the same screenshot.

Enterprise tier Purview licensing remains a prerequisite on top of the metered charges. This is additive cost, not a substitute.

Purview is not talking natively to Box or Salesforce. Before you can apply a policy to one of these apps, that app has to be connected to Microsoft Defender for Cloud Apps through an app connector, and Purview uses those existing connectors to reach it. The connector layer did not disappear. What changed is where policy is defined, classified and enforced.

The PDF gap and the missing simulation mode are the two I would raise first in any customer conversation. The first decides what you can credibly claim about coverage. The second decides how you have to sequence the rollout. And the whole feature still carries the preview banner, with general availability starting early September 2026 and completing in late October according to the message center.

Five minutes in your own tenant

• Open the DLP locations page and check which of the third party entries your tenant actually shows. Phased rollout means the documentation is not the answer, your wizard is.
• Filter your policy list for anything scoped to Instances. That is your migration backlog, and it expires on 6 January 2027.
• Open Defender for Cloud Apps and list the file policies targeting the same apps. Those have to go before the Purview policy goes live.
• Check whether pay as you go consent exists and whether the tenant is linked to an Azure subscription. If procurement is not in the room, the pilot stalls here.
• Estimate the file count per connected instance. 1,000 files equal one data asset, so the scope decision and the invoice are the same decision.
• Decide who owns cost monitoring in Azure Cost Management. This is the question nobody asks until month two.

What this actually signals

Stripped of the screenshots, the direction is consistent with everything else Purview has shipped in the last two years. One classification engine, one policy surface, progressively more data sources pointed at it, and the connector ecosystem demoted to plumbing. Retiring Instances rather than maintaining it alongside the new model is the strongest evidence that Microsoft means it. Consolidation is harder than addition, and it is the part customers feel.

The commercial boundary, meanwhile, is drawn very precisely. Per user for Microsoft 365, metered for everything else. The wizard blurs the technical line between Microsoft and non Microsoft workloads while the billing model keeps it perfectly sharp. Both things are true at once, and only one of them shows up in a demo.