Before your first citizen developer builds their first production flow, your governance baseline needs to be in place. This lesson walks through configuring Default Environment DLP policies, classifying Microsoft first-party connectors, setting trial license boundaries, and enabling Managed Environments — so makers can move fast without creating compliance risk.
Imagine it's Monday morning and your company has just rolled out Microsoft 365 licenses to 2,000 employees. By Wednesday, a well-meaning analyst in the finance department has built a flow that automatically forwards every new email from a shared mailbox to their personal Gmail account — no malicious intent, just someone solving a real problem with the tools in front of them. By Friday, your CISO has questions.
This scenario plays out constantly in organizations that skip maker onboarding controls. Power Automate is deliberately easy to start with. That accessibility is a feature, not a bug. But it means the platform can sprawl in ways that create compliance risk, data leakage, and licensing chaos before your governance team even knows a problem exists. The good news is that Microsoft has built a rich set of administrative controls specifically designed to let you enable citizen development while constraining where it can go. Setting those controls up before the first production flow is built is orders of magnitude easier than retrofitting them afterward.
By the end of this lesson, you'll know how to configure the default environment so it can't be used for production work, how to write Data Loss Prevention policies that govern first-party connectors (the Microsoft-owned ones like SharePoint, Outlook, and Teams), and how to draw clear boundaries around trial licenses so that experimental flows never quietly graduate into production without proper licensing review.
What you'll learn:
This lesson assumes you have a Microsoft 365 tenant with a Power Platform license (Microsoft 365 plans include default Power Automate capabilities). You should be comfortable navigating the Microsoft 365 Admin Center and have at least read access to the Power Platform Admin Center at admin.powerplatform.microsoft.com. You don't need prior Power Automate governance experience — we'll build everything from first principles.
Every Microsoft 365 tenant gets exactly one Default Environment, created automatically and named something like "Contoso (default)." Every licensed user in your tenant has the Maker role in this environment by default. That means they can create flows, apps, and connections the moment they log in to Power Automate — no IT approval required.
The Default Environment isn't bad by design. It exists so that individuals can experiment and learn. The problem is that without guidance, people treat it as the only environment, and production work ends up there alongside experimental junk. When someone then leaves the organization, their flows — which may be processing real business data — are owned by an account that's about to be disabled. When you try to apply a restrictive DLP policy to the Default Environment, you affect every single maker in your company simultaneously. There's no clean separation.
The right mental model is this: the Default Environment is a sandbox for personal productivity experiments, not a place where business processes live. Your job as the administrator is to make that expectation structural, not just documented in a wiki nobody reads.
Key insight
You cannot delete or rename the Default Environment (beyond changing its display name), and you cannot remove the automatic Maker role grant. What you can do is apply DLP policies that severely limit what flows in the Default Environment can actually connect to, and then create purpose-built environments for legitimate use cases.
To see what you're working with, navigate to the Power Platform Admin Center and click Environments in the left navigation. You'll see a list of all environments in your tenant. The Default Environment is marked with a "(default)" suffix. Click into it and review the Settings tab — you'll find options for security roles, DLP policies scoped to this environment, and the environment type (it will show as "Production," which is a slightly misleading label for what is functionally a shared sandbox).
The most common mistake administrators make is trying to prevent all activity in the Default Environment. This fails because it frustrates legitimate learners and creates shadow IT — people find workarounds. Instead, the goal is to make the Default Environment safe for low-stakes experimentation while making it structurally incapable of touching sensitive data.
You accomplish this primarily through DLP policy. A Data Loss Prevention (DLP) policy in Power Automate is a set of rules that controls which connectors can be used together in the same flow. You can think of it like a permissions matrix: some connectors are in a "Business" group (approved for sensitive data), some are in a "Non-Business" group (personal or consumer services), and some are "Blocked" entirely. Connectors in different groups cannot be used together in the same flow.
For the Default Environment specifically, a productive approach is to create a DLP policy that:
Blocks all premium connectors — connectors that require a Power Automate Premium license (formerly Per User or Per Flow). If someone has a trial license, they can technically use premium connectors, but blocking them in the Default Environment prevents trial-driven experiments from accidentally connecting to your SAP system or Salesforce org.
Keeps Microsoft 365 first-party connectors in "Business" — SharePoint, Outlook, Teams, OneDrive for Business, and Planner are fine to leave accessible. These are the tools people actually want to automate.
Moves consumer services to "Non-Business" or "Blocked" — Gmail, Dropbox, Twitter, and similar personal services should not coexist with SharePoint in a Default Environment flow.
To create this policy, go to the Power Platform Admin Center, select Policies → Data policies in the left nav, and click New policy. Give it a name like "Default Environment — Learning Guardrails." When asked to choose environments, select "Add multiple environments" and pick only the Default Environment. Then work through the connector classification screen: use the Prebuilt connectors list to find each connector and assign it to Business, Non-Business, or Blocked using the action menu next to each one.
Tip
Microsoft provides a filterable connector list in the DLP policy builder. Filter by "Publisher: Microsoft" to quickly see all first-party connectors. You can then multi-select and assign them to the Business group in one action, which is much faster than handling them individually.
For a deeper dive into how connector classification, boundary rules, and policy enforcement interact across your entire environment fleet, see Configuring Data Loss Prevention Policies for Enterprise Cloud Flows: Connector Classification, Boundary Rules, and Policy Enforcement Across Environments.
First-party connectors — the ones Microsoft builds and maintains for its own services — deserve special attention during onboarding configuration because they create a false sense of safety. "It's all Microsoft, so it must be fine" is a thought that leads to flows that exfiltrate data from a secure SharePoint site to a public-facing Power Pages form, all without leaving the Microsoft ecosystem.
The connectors you need to think carefully about during onboarding are:
SharePoint — Probably the most sensitive connector in most organizations because it's where documents, HR records, and financial reports live. It should be in "Business," but consider whether your Default Environment DLP policy should also restrict which SharePoint actions are available. (Note: DLP policies cannot currently restrict at the action level — that's a connector-level control — but you can supplement with SharePoint site permissions so that sensitive sites aren't accessible even if the connector works.)
Outlook / Office 365 Outlook — This connector can send email on behalf of users and read their inbox. Leaving it unrestricted in the Default Environment means any maker can build a flow that reads every email in a shared mailbox and forwards it somewhere. Keep it in "Business," and ensure your organization's email security policies are doing their part.
Microsoft Teams — The Teams connector lets flows post messages, create channels, and add members. In the Default Environment, this is generally low risk, but think about whether you want makers experimenting with bot-style automations in Teams before they understand the governance implications.
Microsoft Forms and Power BI — Both are useful for dashboarding and data collection experiments. Keep them in "Business" in the Default Environment; they're unlikely to be data exfiltration vectors on their own.
HTTP and HTTP with Azure AD — These are the connectors that let a flow call any arbitrary URL. The HTTP connector is classified as premium in most license plans, so it will be naturally blocked if you follow the premium connector blocking strategy above. But double-check, because the HTTP with Azure AD connector has had classification changes over time.
Warning
The "HTTP Request" trigger (which allows a flow to receive incoming HTTP calls) and the HTTP action connector are different things. Make sure you review both in your DLP policy. Allowing flows to receive arbitrary HTTP requests in the Default Environment opens the door to flows that act as webhook endpoints for external systems — a production pattern that doesn't belong in a learning environment.
One practical technique: before finalizing your Default Environment DLP policy, export the current list of all flows in the Default Environment from the Power Platform Admin Center (Admin Center → Environments → Default Environment → Resources → Cloud flows). Review what connectors existing flows are already using. A DLP policy that breaks dozens of existing flows on day one will erode trust in the governance program before it has a chance to work.
Power Automate trial licenses are a common source of governance confusion. When a user signs up for a 90-day Power Automate Premium trial (which they can initiate themselves through the Power Automate web app without IT involvement), they get access to premium connectors, higher API request limits, and the ability to create flows in environments where they'd otherwise be limited. That's powerful — and it means a curious employee can stand up a flow connected to your Salesforce org, your SQL Server, and an external HTTP endpoint, all within an afternoon.
The first boundary to understand: trial licenses attach to the user, not to the environment. A user with a trial license can use premium connectors in any environment where they have Maker permissions, which in the Default Environment means all of them. This is why your DLP policy on the Default Environment matters so much — it's the constraint that stays in place regardless of what license the maker holds.
The second boundary to understand: trial flows are not automatically decommissioned when the trial expires. When a trial license expires, flows using premium features will be disabled (they stop running), but they won't be deleted. If the user then gets a proper paid license, those flows come back to life. This creates a pattern where a trial is used to build something, the IT team approves a license, and a flow that was never through any review process is suddenly running in production.
To address this, configure the following in the Power Platform Admin Center:
Disable self-service trial signup at the tenant level. In the Microsoft 365 Admin Center, go to Settings → Org settings → Services → User owned apps and services. Look for the toggle that controls whether users can start trials themselves. Disabling this forces all trial requests through IT, which gives you a review gate.
Note
Disabling self-service trials can be disruptive if announced without context. The better approach is to pair this control with a clear, fast process for requesting a trial — a form that gets approved within one business day, for example. If governance feels faster than self-service, people will use it.
Create a dedicated "Makers — Trial" environment. Rather than letting trial-licensed makers use the Default Environment, provision a separate environment specifically for trial users. Apply a DLP policy that allows premium connectors but excludes your production data sources (your production SharePoint tenant root, your ERP connectors, etc.). Set this environment as a true sandbox — it should be easy for an admin to wipe it. This way, trial users get real access to premium features without touching production data.
Set environment capacity limits. Each Power Platform environment has storage capacity. In the Power Platform Admin Center, under the environment settings, you can see capacity consumption. While you can't hard-cap the number of flows or runs in a standard environment, you can monitor and alert. The Power Platform Admin Center for Flow Owners article covers these monitoring capabilities in detail.
Managed Environments is a Power Platform feature (included with Power Apps Premium, Power Automate Premium, and certain Microsoft 365 plans) that unlocks a set of governance controls that aren't available in standard environments. For maker onboarding, two features are especially valuable:
Sharing limits let you control how broadly a maker can share a flow. In a standard environment, a maker can share a flow with anyone in the organization — including sharing it as a co-owner, which grants full edit access. With Managed Environments, you can restrict sharing to a maximum number of individuals and prevent sharing with the entire organization or broad security groups. This matters for onboarding because it prevents a single maker's experimental flow from becoming a widely-shared "production" tool before anyone in IT knows about it.
Weekly digest emails automatically send environment administrators a summary of new flows, apps, and connections created in the environment during the past week. This is passive awareness — you don't have to run a report, the report comes to you. For the Default Environment and any maker trial environment, enabling this digest means you'll know about new activity within days, not months.
To enable Managed Environments, go to the Power Platform Admin Center, select the environment, and in the environment details panel look for the "Enable Managed Environment" option. Once enabled, you'll see a "Managed Environments" settings section where you can configure sharing limits and the weekly digest.
For a comprehensive treatment of what Managed Environments unlock across the governance spectrum, see Managed Environments in Power Platform: Sharing Limits, Weekly Digests, and Maker Governance.
Tip
Enable Managed Environments on the Default Environment first, before anything else. The Default Environment has the most makers and the least governance by default, so the sharing limits and weekly digest provide the most immediate value there.
DLP policies and Managed Environments work best when they're part of a coherent environment strategy. Without a clear environment structure, even well-configured policies feel arbitrary to makers — they just experience friction without understanding why.
A minimal maker onboarding environment structure looks like this:
Default Environment — DLP restricts to Microsoft 365 first-party connectors in Business group only, all premium connectors blocked, Managed Environment with sharing limits enabled. Intended use: personal productivity experiments only.
Makers Sandbox — A dedicated environment for structured learning. Premium connectors allowed, but production data sources excluded via DLP. Trial-licensed users work here. Managed Environment with weekly digest. Flows here never go to production; they're rebuilt in development environments when a real project starts.
Development, Test, Production environments — These are where real projects live, managed through proper ALM (Application Lifecycle Management) processes. Makers don't have direct production access; flows are promoted through the pipeline. See Deploying and Managing Power Automate Solutions Across Environments for how this promotion process works.
The key principle: every environment should have a documented purpose and a DLP policy that enforces that purpose. If you can't write a one-sentence description of what a given environment is for, it shouldn't exist yet.
For more detail on how to think through the Dev/Test/Production split, the Environment Strategy for Power Platform: Separating Dev, Test, and Production lesson is the right next read.
This exercise walks you through configuring a minimal but real governance baseline for the Default Environment. It should take about 30–45 minutes if you have Power Platform admin access.
Step 1: Audit current Default Environment flows. In the Power Platform Admin Center, navigate to Environments → select the Default Environment → Resources → Cloud flows. Export or screenshot the list of existing flows. Note which connectors each flow uses. This is your impact assessment — any DLP policy change that would break these flows needs to be handled before or during rollout.
Step 2: Create a DLP policy for the Default Environment. Go to Policies → Data policies → New policy. Name it "Default Environment Baseline." Scope it to the Default Environment only. In the connector classification screen:
Step 3: Enable Managed Environments on the Default Environment. From the Default Environment details page, click Enable Managed Environment. Once active, go to the Managed Environments settings and:
Step 4: Document and communicate. Write a short internal note (even just an email to your IT team) explaining what you configured and why. Include the one-sentence purpose of the Default Environment ("personal productivity experiments only, not for business processes or production data"). This documentation is the beginning of your governance playbook.
Step 5: Validate. Log in as a test user who has a standard Microsoft 365 license (no Power Automate Premium). Go to Power Automate, navigate to the Default Environment, and try to create a new flow using the Gmail connector. You should see the connector appear as unavailable or see an error when you try to save the flow citing DLP policy violation. That error message is governance working exactly as intended.
"My DLP policy doesn't seem to be applying to existing flows." DLP policies don't retroactively disable existing flows that were built before the policy was created — they prevent those flows from being edited or saved going forward if they violate the policy, and they may suspend flows on a delay. If you need immediate enforcement, you may need to manually disable violating flows. Use the flow audit in the Power Platform Admin Center to identify which flows use connectors that conflict with your new policy.
"A maker says they can still use a Blocked connector." First, confirm the DLP policy is scoped to the correct environment — it's easy to accidentally scope a policy to "all environments except" when you meant "only this environment." Second, check if there's a tenant-level DLP policy that has a more permissive classification for the same connector; the most restrictive policy wins, but only if both policies are properly scoped. Third, confirm the maker is actually working in the Default Environment and not in a different environment where your policy doesn't apply.
"Users are upset that they can't use connectors they used to have." This is a change management problem as much as a technical one. Before applying restrictive DLP policies to the Default Environment, send an announcement explaining the change, why it's happening, and what alternatives exist (like the Makers Sandbox environment). Offer a feedback window. Governance that's imposed without communication generates resistance; governance that's explained and paired with better alternatives generates appreciation.
"I accidentally applied the Default Environment DLP policy to all environments." This is painful but recoverable. Go back to the DLP policy in question, click Edit, and on the environment scope screen, change the scope back to "Add multiple environments" and select only the Default Environment. Save the policy. Changes propagate within a few minutes. Review any environments that were affected in the interim — flows that were suspended due to the incorrect policy may need to be manually re-enabled.
"Trial users are creating flows in the Default Environment even though I told them not to." Policy documents don't override human behavior; technical controls do. If trial users need access to premium connectors for learning, give them access to the Makers Sandbox environment explicitly. If you want to prevent them from using the Default Environment, consider creating a security group for trial users and using environment-level security to restrict their Maker role in the Default Environment (remove the automatic Maker role for a specific security group, if your license tier supports it).
Warning
Be cautious about governance controls that are only documented but not technically enforced. Policies that depend on people remembering to follow them will drift. Every governance rule you care about should have a corresponding technical enforcement mechanism.
You've now built the foundational layer of Power Automate maker governance. Let's recap what you've put in place:
The Default Environment has a DLP policy that restricts it to Microsoft 365 first-party connectors in the Business group, blocks premium connectors, and moves consumer services to Non-Business. Makers can still experiment with real tools, but they can't accidentally connect sensitive data to personal services or production systems.
First-party connector classification is deliberate: SharePoint, Outlook, Teams, and similar services are in Business; consumer equivalents are in Non-Business or Blocked. You've thought through which Microsoft-owned connectors carry real data risk (Outlook, SharePoint) versus lower risk (Notifications, Approvals).
Trial license boundaries are enforced both through DLP (trial users in the Default Environment face the same connector restrictions as everyone else) and through environment structure (a Makers Sandbox gives trial users a safe place to explore premium features without touching production data).
Managed Environments are enabled on the Default Environment, providing sharing limits that prevent experimental flows from becoming de facto production tools and weekly digest emails that give administrators passive awareness of new activity.
This is a solid foundation, but governance doesn't stop at the Default Environment. Your next priorities should be:
Establish tenant-wide DLP policies that apply to all environments as a baseline, complementing the environment-specific policies you've set. The full picture of how tenant-level and environment-level policies interact is covered in Securing Power Automate Flows in Production: Managing Credentials, Connection References, and Data Loss Prevention Policies.
Set up the CoE Toolkit to get visibility into flow ownership, usage, and compliance across your entire tenant — not just the Default Environment. Auditing and Governing Power Automate at Scale: Flow Ownership Policies, Usage Analytics, and Automated Compliance Reporting with CoE Toolkit walks you through the setup.
Design your Dev/Test/Production environment structure so that when a maker is ready to move a flow from experiment to real project, there's a clear, supported path that doesn't require them to circumvent governance to get things done.
The goal of maker onboarding controls isn't to slow down citizen developers — it's to give them a clear runway so they can move fast without breaking things that matter.