[object Object]

Most tenants have one Data Loss Prevention policy: “block everything except Dataverse and SharePoint”. Makers immediately learn to work around it. The policy gets weakened. Six months later it is “allow most connectors”, which is no policy at all. The fix is not stricter rules — it is tiered policies, scoped to environment groups, with deliberate paths for legitimate edge cases.

What DLP actually controls

A DLP policy assigns every connector to one of three groups: Business, Non-Business, Blocked. Flows and apps cannot use connectors from both Business and Non-Business in the same artifact. Blocked connectors are unusable.

The policy applies at the environment level — either all environments or a named set, with optional exclusions. In tenants with hundreds of environments, the scoping logic matters more than the connector classification.

The tiered pattern

Three policies per tenant:

  1. Production-strict: applied to all production environments. Business = Dataverse, SharePoint, Office 365 Outlook, Teams. Non-Business = nothing (effectively forbidden). Blocked = everything else.
  2. Production-business: applied to a named set of production environments that need additional connectors (HTTP, Azure SQL, specific SaaS). Business is the strict set plus the named additions. Non-Business is still tightly scoped.
  3. Sandbox-permissive: applied to developer and personal productivity environments. Business = the usual enterprise set. Non-Business = social, AI, custom HTTP. Allows makers to experiment without breaking governance, because production paths are separate.

The trick is the environment-grouping discipline. Every environment lives in exactly one tier. Movements between tiers go through change control.

The connector list nobody curates

Microsoft adds connectors monthly. Your DLP policies inherit a default classification for new connectors. The default is “Non-Business”, which sounds safe — until you discover that “Non-Business” in your production-strict policy effectively means “blocked”, and a new Microsoft-published connector you would have wanted is now unusable.

Set the default to Blocked. Force new connectors through a review step. The review is a Power Automate flow:

trigger: When a new connector appears in tenant connector list
actions:
  - notify_dlp_owner:
      message: "New connector: {connector.displayName}. Review and classify."
  - wait_for_review: 5d
  - on_review_complete:
      - if_business: AddConnectorTo(ProductionStrict.Business)
      - if_non_business: AddConnectorTo(SandboxPermissive.NonBusiness)
      - if_block: Leave as Blocked

Run this monthly and you stay current. Without it, drift accumulates.

Custom connector classification is per-policy

Custom connectors created by makers inherit the default group of each policy. They show up in the connector list per environment. Three rules:

  • Custom connectors in production environments must be in Business or Blocked. Never Non-Business.
  • Custom connector lifecycle: created in sandbox, reviewed, promoted as a solution component to production, classified explicitly.
  • Custom connector audit: monthly, list all custom connectors per environment, owner, last-modified, classify.

HTTP and HTTP-with-AD as the danger pair

The HTTP connector lets a flow call any URL. The HTTP-with-AD connector adds the maker’s identity. Together they let a maker exfiltrate Dataverse data to any endpoint they can authenticate to. Block both by default. Allow only in environments where the workflow demands it, and require a documented approval per flow.

A subtler risk: third-party connectors that wrap HTTP. The Azure Logic Apps connector and certain partner connectors can make arbitrary HTTP calls under the hood. Block these the same way you block raw HTTP.

Policy as code

Author DLP policies as code, not in the UI. The Power Platform admin endpoints accept policy JSON via the management API. Source-control the JSON. Apply via pipeline.

{
  "displayName": "Production-Strict",
  "definition": {
    "constraints": {
      "businessDataGroup": [
        "shared_commondataserviceforapps",
        "shared_sharepointonline",
        "shared_office365",
        "shared_teams"
      ],
      "nonBusinessDataGroup": [],
      "blockedConnectors": "*"
    },
    "environmentType": "OnlyEnvironments",
    "environments": ["${env:prod-strict-envs}"]
  }
}

The pipeline computes the current connector list from the tenant and emits the blockedConnectors as a concrete set rather than wildcard. Apply via PowerShell with the Power Platform admin module. Diff each apply for visibility.

The override mechanism

Makers will hit DLP limits. Provide a clean override path:

  1. Maker raises a request via a SharePoint form.
  2. Form captures: target connectors, business justification, data classification, owner.
  3. Governance team reviews and either approves a tier upgrade, creates an environment-specific policy, or denies.
  4. Approved exceptions become a new entry in the policy-as-code repository. The next pipeline run applies it.

The mechanism matters more than the rules. If the override path is invisible, makers route around the policy via personal environments and you have lost.

What auditing looks like

Three reports, monthly:

  • Connector-by-connector classification across all policies.
  • Flows and apps that touch connectors from the business group, by environment.
  • DLP policy violations (attempted but blocked usages).

The Power Platform admin center exposes the data; the audit is shaping it into something a security review can consume.

See also

Dataverse security role anti-patterns — DLP gates connector access; security roles gate data access. They are complementary controls and both need design.

Pixel notes

If you build a DLP override request form, show the policy’s connector classification inline. Makers do not understand “Business vs Non-Business” labels in the abstract. Seeing “this connector is currently Non-Business in your environment, so it cannot be combined with Dataverse” makes the workflow self-explanatory.

Forge notes

The Power Platform admin module’s policy commands occasionally lag the UI by hours. Race conditions exist when two pipelines apply concurrently. Serialize policy edits through a single CI job with a lock file. The lockfile is in source control and contains a timestamp; refuse to apply if it is younger than 30 minutes.

Key takeaways

  • One policy is no policy. Tier production-strict, production-business, sandbox-permissive.
  • New connectors default to Blocked. Force a review.
  • Block HTTP and HTTP-with-AD by default. Allow per-environment with documented approval.
  • Author policies as code in source control. Apply via pipeline.
  • Provide a clean override path; invisible policy gets routed around.
[object Object]
Share