Power Platform data policies for a small firm: how to group connectors so client data cannot leak

Once a few people in your firm start building Power Automate flows, someone will eventually connect a client folder in SharePoint to something it should never touch: a personal Gmail account, a free file-sharing service, a social media connector. Nobody intends to leak data. The tool simply lets any licensed user combine any connectors they can sign in to, unless an administrator has set limits.

The direct answer: Power Platform data policies (formerly called DLP policies) let an admin sort every connector into three groups: Business, Non-business and Blocked. A flow or app can only use connectors from one group, and Blocked connectors cannot be used at all. For a 10 to 50 person firm, one tenant-wide policy that puts your approved business systems in Business, blocks the obvious risks and leaves everything else in Non-business covers most of the risk. The rest of this article explains how the groups work and gives a practical starting layout.

How the three groups work

Microsoft's connector classification guide describes the rules, as published in October 2026:

• Business: connectors that hold business data. They can be used together in one flow.
• Non-business: connectors for personal or low-risk use. They can also be used together, but never with a Business connector.
• Blocked: cannot be used in any app or flow where the policy applies.

The key sentence is that connectors in different groups cannot share data. If SharePoint is in Business and Gmail is in Non-business, nobody can build a flow that copies a SharePoint file to Gmail. That one rule is what stops accidental leaks.

When you create a policy, every connector starts in Non-business, and that group is also the default for any new connector Microsoft adds later. Microsoft recommends keeping it that way, so new services are reviewed before they are allowed near business data.

The connectors you cannot block

Some connectors can be moved between Business and Non-business but never blocked. Microsoft's list of nonblockable connectors includes the core Microsoft 365 ones (SharePoint, OneDrive for Business, Microsoft 365 Outlook, Microsoft Teams, Excel Online (Business), Planner and others) plus core platform connectors such as Dataverse, Approvals and Notifications.

In practice this is not a problem for a small firm: these are the tools your client data already lives in, so they belong in Business anyway. Microsoft points admins who need stricter control of these connectors to its newer advanced connector policies, which use an allowlist model.

A starting layout for a 10 to 50 person firm

Adapt this to your own tools; the principle matters more than the exact list.

Three decisions need more thought:

HTTP connectors

The HTTP, HTTP Webhook and "When an HTTP request is received" connectors can send data anywhere on the internet. Microsoft's guide notes that child flows depend on the HTTP connector, so the group you choose can affect them, and suggests keeping HTTP out of Business in shared environments such as the default environment, then allowing it only in a dedicated environment with a restricted list of makers. For a small firm that means: block or keep HTTP in Non-business in the default environment, and only open it where someone accountable builds flows.

Microsoft also offers connector endpoint filtering, which can allow HTTP calls only to listed addresses. It was still marked as a preview feature in October 2026, and it does not check addresses built at run time from variables, so do not rely on it alone.

Custom connectors

If someone has built a custom connector to an in-house or niche system, it needs a group too. At tenant level, Microsoft's guide says custom connectors are classified by URL pattern, and the catch-all rule is set to "Ignore" by default, which lets custom connectors be used with both Business and Non-business connectors. Change that if custom connectors touch client data.

AI connectors

AI and Copilot connectors are connectors like any other. Decide whether each one has been approved for client data before moving it into Business; until then it stays in Non-business by default. Our article on connecting an AI assistant to your CRM safely covers the questions to ask.

Tenant policy, environment policy, or both?

Microsoft's guide to managing data policies explains that tenant-level policies are created by a Power Platform administrator and can cover all environments or a chosen set, while environment-level policies cover a single environment. Environment admins cannot edit or override a tenant policy.

When several policies apply to one environment, Microsoft's page on the combined effect of multiple policies says Blocked always wins and Business/Non-business groupings fragment into smaller sets, so makers find connectors they expected to combine no longer can. Microsoft recommends applying as few policies as possible to any environment.

For most small firms, the simple shape is:

1. One tenant-wide policy covering every environment, with the layout above.
2. One extra environment for flows that need HTTP or other restricted connectors, with a short list of makers, if you need it at all.
3. A stricter environment for any flow that handles health or other sensitive data, if that applies to you. Our article on Power Automate and the HIPAA BAA explains why clinics separate these.

Microsoft's walkthrough also notes that an environment with no policy applied lets apps and flows combine any connectors, so make sure test or trial environments are not quietly exempt.

What happens to flows that already exist

Before you save a policy, list the flows people already run. Microsoft's data policy overview describes what happens next: flows and apps that violate the new policy are suspended, connections to a blocked connector are disabled, and anything still trying to use them fails at run time. Enforcement usually takes effect within an hour, and Microsoft says it can take up to 24 hours in the largest tenants.

So a careless policy can switch off the intake or invoicing flow someone built two years ago. To avoid that:

• Inventory first. List the flows in each environment, who owns them and the connectors each one uses.
• Find the mixes. Any flow combining a connector you plan to block, or mixing groups, will stop.
• Talk to the owners. Decide whether each flow is rebuilt, moved to another environment, or retired.
• Apply out of hours and check the important flows the next morning.
• Tell people. Microsoft recommends sharing your data policies with makers so they know the rules before they build.

Who should own this

Creating a tenant policy needs the Power Platform Administrator role, according to Microsoft's guide. In many small firms that sits with an outside IT provider. Agree who decides which connectors are approved (usually the managing partner or operations lead, with input from whoever handles data protection) and who changes the policy. Check with your lawyer or compliance lead whether your client agreements or professional rules require specific controls; a data policy is a technical guardrail, not a compliance answer by itself. Our guide to what happens to automations when an employee leaves covers the ownership side of flows themselves.

How Flow Mesh helps

Every engagement starts with a first call, then a stack audit scoped in writing before it starts. For Microsoft 365 firms it covers which flows exist, which connectors they use and how your environments are set up, and gives every tool a verdict (keep, configure, consolidate or replace) with a written scope. Any changes are quoted in writing after the audit and made inside your own tenant.

Key takeaways

• Data policies sort connectors into Business, Non-business and Blocked; a flow can only use connectors from one group, and Blocked ones not at all.
• New connectors land in Non-business by default; keep it that way so new services are reviewed first.
• Put your client-data systems in Business, block personal email, consumer file sharing and social media, and treat HTTP and custom connectors with care.
• Use one tenant-wide policy and as few extra policies as possible; stacked policies fragment connector groups.
• Inventory existing flows before saving a policy, because violating flows are suspended and their connections disabled.