Environments and Security
Environments isolate your Power Platform data and apps. The security model layers Entra ID, security groups, roles, and DLP policies to control who can access what — and what connectors they can use together.
What is an environment?
Think of environments as separate apartments in the same building.
Each apartment has its own locks, its own furniture, and its own rules. The people in Apartment A cannot walk into Apartment B — even though they share the same building (your Microsoft 365 tenant).
In Power Platform, each environment has its own apps, flows, Dataverse database, and security settings. Your production apps live in one apartment. Your test apps live in another. Developers experiment in a third.
Aisha — the IT admin at Coastal Logistics — manages the keys to every apartment.
Environment types
| Environment Type | Purpose | Dataverse | Who Can Create | Reset/Copy |
|---|---|---|---|---|
| Default | Auto-created for every tenant. Shared by all users. Good for personal productivity apps. | Optional (can add) | Automatic | No |
| Production | Live business applications. Full data, full security, full capacity. | Yes | Admins | No reset (copy yes) |
| Sandbox | Testing and development. Can be reset to blank or copied from Production. | Yes | Admins | Yes |
| Developer | Individual developer use. Free, low capacity. One per user. | Yes | Users (self-service) | No |
| Trial | Short-term evaluation (30 days). Auto-deleted after expiry. | Yes | Users (self-service) | No |
Aisha’s environment strategy
Coastal Logistics uses three environments:
- Default — everyone has access for personal Power Apps and Power Automate flows
- Coastal - Dev (Sandbox) — the maker team builds and tests new apps here
- Coastal - Production (Production) — approved apps only, accessed by all 800 staff
When the maker team finishes an app in Dev, Aisha promotes it to Production using a managed solution. If something goes wrong in Dev, she resets the sandbox without touching Production.
What is the default environment?
The default environment is created automatically with every Microsoft 365 tenant. Every licensed user has access to it — you cannot restrict it with a security group.
This is why the default environment should be used only for personal productivity apps (like “my expense tracker” or “my team dashboard”). Critical business apps should run in dedicated Production environments where Aisha controls who has access.
The security model — five layers
Power Platform security works in layers. Think of it as concentric rings — each layer narrows access further.
Layer 1: Microsoft Entra ID (identity)
Every Power Platform user authenticates through Microsoft Entra ID (formerly Azure Active Directory). No anonymous access. If you are not in the Entra ID tenant, you cannot reach any environment.
Layer 2: Environment security groups
Aisha assigns an Entra ID security group to each environment. Only members of that group can access the environment. This is the first gate after authentication.
- Default environment: No security group restriction (all licensed users)
- Coastal - Dev: Only the “PP Makers” security group (12 people)
- Coastal - Production: The “All Coastal Staff” security group (800 people)
Layer 3: Security roles
Inside an environment, security roles control what users can do with Dataverse data. Roles define Create, Read, Write, Delete, Append, and Assign permissions at the table level.
| Security Role | What It Grants |
|---|---|
| System Administrator | Full access to everything in the environment |
| System Customizer | Can create and edit tables, apps, and flows — but cannot manage security |
| Environment Maker | Can create apps, flows, and connections — but cannot modify Dataverse schema |
| Basic User | Can run apps and use existing data — limited create/edit |
Aisha assigns “Basic User” to all 800 staff in Production, and “Environment Maker” to the 12-person maker team in Dev.
Layer 4: Column-level security
Some columns contain sensitive data. Column-level security profiles restrict which users can read or update specific columns — even if they have access to the table.
Example: The Equipment Inspection table has a “Repair Cost” column. Only the Finance team can see it. Everyone else sees the inspection details but the cost column is hidden.
Layer 5: Row-level security (record ownership)
Dataverse supports row-level security through ownership and sharing:
- User-owned tables: Each row has an owner. Users see only their own rows unless granted broader access via security roles (Business Unit, Parent-Child, or Organisation-wide).
- Organisation-owned tables: All users with table access can see all rows.
How row-level access scopes work
Security roles in Dataverse grant permissions at four scope levels:
- User — only records you own
- Business Unit — records owned by anyone in your business unit
- Parent: Child Business Unit — your business unit and its child units
- Organisation — all records in the environment
Aisha gives inspectors “User” scope on Equipment Inspections — each inspector sees only their own inspections. Supervisors get “Business Unit” scope to see all inspections in their region. Safety managers get “Organisation” scope to see everything.
Data Loss Prevention (DLP) policies
DLP policies control which connectors can be used together. They prevent users from accidentally (or intentionally) moving sensitive data to unauthorised services.
Connectors are classified into three groups:
| Group | What It Means | Example Connectors |
|---|---|---|
| Business | Trusted, approved connectors that can share data with each other | SharePoint, Dataverse, Outlook, Teams |
| Non-business | Consumer or external connectors that cannot share data with Business connectors | Twitter, Gmail, Dropbox |
| Blocked | Connectors that cannot be used at all in the environment | Any connector the admin blocks |
The rule: An app or flow can only use connectors from the same group. If SharePoint (Business) and Twitter (Non-business) are in different groups, no app can use both.
Aisha’s DLP policy
Aisha creates a DLP policy for the Production environment:
- Business group: Dataverse, SharePoint, Outlook, Teams, OneDrive, Excel Online
- Non-business group: All remaining connectors
- Blocked: Social media connectors, personal email connectors
This means a Power Automate flow can send Dataverse data to SharePoint (both Business), but cannot send it to a personal Gmail account (Non-business).
DLP policies apply at tenant or environment level
Admins can create DLP policies that span the entire tenant (all environments) or target specific environments. If both a tenant-level and environment-level policy apply, the most restrictive rule wins.
Best practice: Create a tenant-wide policy with baseline restrictions, then create environment-specific policies for additional controls.
🎬 Video walkthrough
🎬 Video coming soon
Environments and Security — PL-900 Domain 2
Environments and Security — PL-900 Domain 2
~14 minFlashcards
Knowledge Check
Aisha wants to prevent Power Automate flows in the Production environment from sending Dataverse data to personal email services. What should she configure?
Which Power Platform environment type can be reset to a blank state for re-testing?
In the Power Platform security model, what controls whether a user can see only their own records versus all records in a table?
Next up: Admin centers and governance — the portals Aisha uses to manage everything, plus data privacy and accessibility.