Establishing Power Platform Tenant Baseline Governance: Configuring Default Environment Policies, Connector Restrictions, and Maker Access Controls Before Your First Production Flow

Introduction

Imagine you've just been handed the keys to a new Power Platform tenant. Your organization is excited — citizen developers want to build automations, IT wants to modernize workflows, and leadership wants to see results fast. You could jump straight in and let people start building flows. In fact, that's exactly what most organizations do. And three months later, they're dealing with employees accidentally exporting customer data to personal Dropbox accounts, flows built by people who've since left the company running with orphaned credentials, and a patchwork of undocumented automations that nobody dares touch.

Governance isn't a bureaucratic tax on productivity. It's the foundation that makes sustainable productivity possible. Setting up your tenant's baseline governance configuration before anyone builds a production flow is like framing a house before hanging drywall — it takes a few hours now and saves months of remediation later. In this lesson, you'll learn exactly what knobs to turn, which defaults are dangerous, and how to structure access controls so your organization can build confidently without creating hidden risk.

By the end of this lesson, you'll have a clear, actionable governance baseline that covers the three pillars every enterprise Power Platform deployment needs: environment policy, connector restrictions, and maker access controls.

What you'll learn:

• How Power Platform tenant defaults work and why they're insufficient out of the box
• How to configure and scope Data Loss Prevention (DLP) policies across environments, including the critical default environment
• How to classify connectors into Business, Non-Business, and Blocked tiers and why the boundary matters
• How to control who can create environments, build flows, and share automations across your tenant
• How Managed Environments extend governance with sharing limits, weekly digests, and usage visibility

---

Prerequisites

You'll get the most from this lesson if you have:

• An understanding of what Power Platform environments are and how they relate to each other. If you're new to environments, read Environment Strategy for Power Platform: Separating Dev, Test, and Production first.
• Access to a Power Platform tenant where you have the Global Administrator or Power Platform Administrator role, or a developer plan tenant you can experiment in.
• Basic familiarity with what Power Automate flows do — that you're triggering actions between systems using connectors.

You do not need prior governance experience. We're building that from scratch right here.

---

Understanding What You're Actually Governing

Before you touch a single setting, you need a mental model of what Power Platform governance controls. Think of your tenant as a city. The tenant is the city limits — one organization, one Azure Active Directory, one billing relationship with Microsoft. Inside the city, you have environments, which are like neighborhoods: isolated spaces where apps, flows, and data live separately from each other.

Every tenant comes with a Default Environment that Microsoft creates automatically. Every licensed user in your Azure AD can access it, build in it, and share from it. That sentence should make every security-conscious person uncomfortable, and rightfully so — the default environment is the wild west by design, and your first governance task is taming it.

Inside environments, connectors are the pipelines that flows use to talk to external systems. SharePoint, Outlook, Salesforce, Twitter, SQL Server, custom HTTP endpoints — these are all connectors. Some are appropriate for business data. Some are appropriate for personal use. Some should never be used from a corporate tenant at all. Governance lets you draw those lines explicitly rather than hoping people guess correctly.

Finally, makers are the people who build things. Not all makers should have identical privileges. A trained developer building a critical ERP integration needs different access than a sales rep who wants to automate their weekly report email. Governance lets you calibrate that distinction.

---

The Default Environment Problem

Let's be specific about why the default environment demands immediate attention. When a user in your organization visits make.powerautomate.com for the first time, they land in the default environment. If they build a flow there — say, one that reads from SharePoint and writes to Excel — that flow runs in the default environment. By default, they can share it with anyone in the organization. By default, it can connect to any available connector.

This creates several concrete risks:

Data exfiltration: Without connector restrictions, a well-meaning employee could build a flow that reads from your corporate CRM and posts results to a personal Gmail or Dropbox. No malice required — they're just trying to be productive.

Orphaned automations: Flows in the default environment are often built by individual users under their personal identity. When that person leaves, their flows break, but nobody knows who to contact. We cover the ownership lifecycle in depth in Auditing and Governing Power Automate at Scale.

License sprawl: Unlicensed or incorrectly licensed flows run in the default environment and create unexpected capacity consumption.

Your first governance action is to apply a restrictive DLP policy to the default environment and leave it there permanently. The default environment should be treated as a sandbox with guardrails, not a production workspace.

---

Configuring Data Loss Prevention Policies

Data Loss Prevention (DLP) policies are the primary technical mechanism for connector governance in Power Platform. A DLP policy takes every connector available in your tenant and sorts them into one of three buckets:

• Business: Connectors approved for corporate data. Flows can combine these freely.
• Non-Business (Personal): Connectors appropriate for non-corporate use. These can connect to each other but cannot share data with Business connectors in the same flow.
• Blocked: Connectors that cannot be used at all in any flow within the policy's scope.

The critical rule is the boundary: a single flow cannot use connectors from both Business and Non-Business groups. This is how you prevent the SharePoint-to-Dropbox scenario — put SharePoint in Business and Dropbox in Non-Business, and no flow can bridge them.

Navigating to DLP Policy Configuration

Open the Power Platform Admin Center at admin.powerplatform.microsoft.com. Sign in with your administrator account. In the left navigation panel, select Policies, then Data policies. You'll see any existing policies listed here, along with their scope.

Click New policy in the top ribbon. The policy creation wizard walks you through five steps: name the policy, assign connectors to Business/Non-Business/Blocked, set scope (which environments the policy covers), and review and create.

Building Your Default Environment DLP Policy

Name the policy something explicit: Tenant-Wide Baseline — Default Environment. Names matter because you'll eventually have multiple policies and need to understand at a glance what each does.

For a baseline governance posture, here's how to classify common connectors:

Business tier (corporate-approved):

• SharePoint
• Microsoft Teams
• Outlook / Office 365
• Microsoft Dataverse
• Azure services (Blob Storage, Service Bus, Key Vault, Functions)
• Approved CRM connectors (Dynamics 365, Salesforce if your org uses it)
• OneDrive for Business (note: this is separate from personal OneDrive)
• Approvals

Non-Business tier (personal/low-trust):

• Personal OneDrive
• Gmail
• Slack (if not your corporate tool)
• Dropbox
• Box
• Social media connectors (Twitter, LinkedIn)

Blocked tier (should not be used from this tenant):

• Any connector with no clear business justification
• HTTP with Azure AD (if you want to control custom API calls centrally)
• Any connector to competing or sensitive external platforms depending on your industry

The Non-Business vs. Blocked distinction is subtle but important. Non-Business connectors can be used in flows — just not mixed with Business connectors. Blocked connectors cannot be used at all. If you want to prevent personal Gmail usage entirely, put it in Blocked. If you want to allow it for non-corporate use cases (unlikely in most enterprise tenants), put it in Non-Business.

For a deeper treatment of connector classification strategy, including how to handle the HTTP connector and custom connectors in enterprise environments, see Configuring Data Loss Prevention Policies for Enterprise Cloud Flows.

Setting Policy Scope

When you reach the scope step, you'll choose between:

• All environments: The policy applies everywhere, including environments created in the future.
• All environments except specific ones: Useful for a broad default that excludes your development sandbox.
• Only specific environments: Targeted application.

For your default environment policy, scope it to the default environment specifically. You'll create a separate, potentially more permissive policy for your dev/test environments where makers need more latitude to experiment. Your production environment gets its own tighter policy.

The Tenant-Wide Backstop Policy

Create a second policy scoped to All environments that only contains your absolute prohibitions in the Blocked tier. Things like connectors to known data exfiltration risks, connectors that violate industry regulations, or connectors that Microsoft adds to the catalog that your legal team has specifically prohibited. This policy travels with every environment — even ones your developers create — so there's always a floor below which no one can go.

---

Controlling Who Can Create Environments

By default, any user with a Power Apps or Power Automate license can create a new environment. This is a significant governance gap. Why? Because environments created outside your awareness are environments outside your DLP policies — at least until you discover them and apply policies retroactively.

Restricting Environment Creation

In the Power Platform Admin Center, go to Settings (the gear icon) → Power Platform settings. Under the Environments section, you'll find a toggle: "Who can create production and sandbox environments." Change this from Everyone to Only specific admins.

The admin roles that can still create environments after this change are: Global Administrator, Dynamics 365 Administrator, and Power Platform Administrator. This is appropriate — environment creation should be a deliberate, tracked action, not something that happens organically when someone clicks the wrong button.

You'll also want to review the "Who can create Microsoft Dataverse databases" setting and apply the same restriction. Dataverse databases add storage capacity costs and need to be planned rather than created ad-hoc.

---

Managing Maker Access Controls

Not everyone who has a Power Platform license should have identical building privileges. Maker access controls let you differentiate between users who can view automations, users who can build automations, and users who can build certain types of automations.

The Power Automate License Landscape

Power Automate has two primary user license types:

Power Automate (included with M365): Allows users to build and run flows that use standard connectors and Office 365. This is what most knowledge workers have by default. They can build flows — you need explicit configuration to restrict that.

Power Automate Premium: Required for premium connectors (Dataverse, HTTP, custom connectors) and certain enterprise scenarios. Users without this license simply cannot use premium connectors, which is itself a governance lever.

Understanding this matters because some of your governance comes for free from license enforcement — a user without a Premium license literally cannot build a flow that calls a custom API, regardless of what your DLP policies say.

Sharing and Co-ownership Controls

In the Power Platform Admin Center under Settings → Tenant settings, you'll find controls for flow sharing behavior. Pay particular attention to:

"Who can share flows" — You can restrict the ability to share flows outside of specific security groups. This prevents individual makers from broadly publishing their automations without IT review.

"Share with security groups" — Requiring that flows be shared with defined security groups (rather than individuals or "everyone") makes ownership much easier to audit and maintain.

For production environments specifically, consider enabling Managed Environments — a feature that gives administrators enhanced governance controls including sharing limits, mandatory labeling, and weekly digest emails showing what's being built and by whom. We cover the full Managed Environments feature set in Managed Environments in Power Platform: Sharing Limits, Weekly Digests, and Maker Governance.

Security Groups for Environment Access

Rather than giving all licensed users access to your production environment, use Azure Active Directory security groups to control who can access each environment. This is configured at the environment level in the Power Platform Admin Center.

Navigate to Environments, select your production environment, and click Settings → Users + permissions → Environment security group. Assign an AAD security group here. Only members of that group can access the environment at all — including browsing apps or flows in it.

This creates a clean separation:

• All licensed users → can access the default environment (with your restrictive DLP policy applied)
• Development team security group → can access dev/test environments
• Approved production operators → can access production environments
• Power Platform administrators → can access everything

---

Managed Environments: Extended Governance Controls

Managed Environments is a Power Platform feature (enabled per-environment) that unlocks a governance control surface beyond standard DLP and security groups. Once you enable it on an environment, you gain:

Sharing limits: You can cap how many users or groups a canvas app or flow can be shared with. This prevents one person's experiment from accidentally becoming a tenant-wide critical dependency.

Weekly digest emails: Administrators receive weekly summaries showing which makers are active, what they've built, and how it's being used. This gives you passive visibility without requiring manual auditing.

Solution checker enforcement: Managed Environments can require that solutions pass Microsoft's solution checker before being deployed — catching common quality and governance issues before they reach production.

Data policies (enhanced): Managed Environments gets additional controls around how flows interact with Dataverse.

To enable a Managed Environment, navigate to Environments in the admin center, select the environment, and click Enable Managed Environment in the top ribbon. The setting applies immediately. Note that flows and apps in a Managed Environment require Premium licenses for all makers — this is an important licensing consideration before you flip the switch.

---

Hands-On Exercise

Let's walk through building your tenant's governance baseline from scratch. This exercise assumes you have Power Platform Administrator access.

Step 1: Audit your current state

Before configuring anything, understand what exists. In the Power Platform Admin Center, go to Environments and note every environment that exists. For each one, check: Does it have a DLP policy applied? Does it have a security group restricting access? Write this down — you're establishing a baseline.

Step 2: Create your tenant-wide backstop DLP policy

Go to Policies → Data policies → New policy. Name it Tenant-Wide: Absolute Restrictions. In the connector assignment step, move any connectors your organization has legally or policy-prohibited to the Blocked tier. Leave everything else in Non-Business (the default). Set scope to All environments. Save the policy.

Step 3: Create your default environment DLP policy

Create a second policy named Default Environment: Baseline. Move Microsoft 365, SharePoint, Teams, Outlook, and other approved corporate connectors to Business. Move personal storage and consumer services to Non-Business or Blocked as appropriate. Scope this policy to only the default environment. Save it.

Step 4: Restrict environment creation

Go to Settings → Power Platform settings. Set environment and Dataverse database creation to Only specific admins. Save.

Step 5: Apply a security group to your production environment

Create an AAD security group called PowerPlatform-Production-Makers and add only your approved production builders. In the admin center, navigate to your production environment's settings and assign this security group as the environment access restriction.

Step 6: Verify DLP policy enforcement

In a test account that has access to the default environment, try building a flow that uses both SharePoint (Business) and a connector you've placed in Non-Business. The flow designer should display a DLP violation warning and prevent saving. Confirm this works before declaring your baseline complete.

---

Common Mistakes & Troubleshooting

"My DLP policy doesn't seem to be doing anything." Check the policy scope. A policy scoped to a specific environment won't affect other environments. Also verify the policy status is Active, not draft. Give it 5-10 minutes to propagate after creation — changes aren't always instantaneous.

"I blocked a connector tenant-wide but people in the dev environment still need it." Tenant-wide policies stack with environment-specific policies. If you blocked something at the tenant level, you can't unblock it at the environment level — the more restrictive policy wins. Move absolute prohibitions to the backstop policy and handle per-environment decisions in environment-specific policies.

"A user got around the DLP policy by building a flow in a new environment they created." This is why restricting environment creation (Step 4 above) is non-negotiable. If users can create environments, they can create ungoverned spaces. Check your environment creation settings immediately.

"We enabled Managed Environments on production and now makers get license errors." Managed Environments requires Premium licensing for all makers in that environment. Users with only M365-included Power Automate licenses will lose access. Audit your makers before enabling Managed Environments and provision Premium licenses for those who need continued access.

"I applied a security group to the production environment and now the admin team can't access it." Global Administrators and Power Platform Administrators bypass environment security group restrictions — they always have access. But other admins (like helpdesk roles) won't. Make sure your production security group includes all relevant operational staff, not just developers.

---

Summary & Next Steps

You've now built the mental model and practical steps for a Power Platform governance baseline that protects your organization without strangling productivity. The key principles to carry forward:

• The default environment is always open. Treat it as a managed sandbox, not a production workspace. Apply restrictive DLP and accept that makers will experiment there.
• DLP policies layer and stack. Use a tenant-wide backstop for absolute prohibitions, and environment-specific policies for nuanced rules.
• Restrict environment creation immediately. Ungoverned environments are ungoverned automations.
• Security groups control access; DLP controls behavior. You need both.
• Managed Environments extend your governance surface — but come with Premium license implications.

With this baseline in place, you're ready to start thinking about production flows responsibly. As your automation program matures, your next focus areas should be:

• Setting up solution-aware flows and ALM pipelines so flows can be promoted between environments consistently — covered in Deploying and Managing Power Automate Solutions Across Environments
• Managing credentials safely in production, including connection references and secrets — covered in Securing Power Automate Flows in Production
• Establishing monitoring so you know when flows fail and why — covered in Building a Power Automate Monitoring and Alerting System

Governance isn't a one-time configuration. It's an ongoing practice. But starting with this baseline means every future decision you make is built on solid ground rather than inherited chaos.