# Managing Environments and Data Policies

> Chapter 4 of the Courseiva PL-900 curriculum — https://courseiva.com/learn/pl-900/power-platform-environments

**Official objective:** 2.2 — Describe differences between types of environments and data policies

## Introduction

Managing Environments and Data Policies — this is the invisible scaffolding that keeps your Power Platform apps from crashing into each other and leaking your company's secrets. For the PL-900 exam, you need to know that environments are like separate rooms where apps live, and data policies are the security guards that decide what data can enter or leave those rooms. Understanding this saves you from accidentally deleting your boss's live sales data while you are testing a new feature.

## The Apartment Building Analogy

Your company has just moved into a three-floor apartment building. Each floor is a separate environment in Microsoft Power Platform. The ground floor (your Development environment) is where you try out new furniture arrangements and paint colours — you can make mistakes here because nobody important sees it. The first floor (your Test environment) is where you show a few trusted neighbours your final idea, so they can check if the sofa fits through the door before you order it. The top floor (your Production environment) is where the actual party happens — visitors see this floor, so it must be perfect and stable.

Now, data policies are like the building's rules about what items can be carried between floors. The building manager (your Power Platform administrator) sets a rule: 'No open flames on any floor' (this blocks connectors like Twitter from accessing sensitive data). Another rule might be: 'You can carry bottled water up from the ground floor to the top floor, but you cannot pour it into the electrical sockets' (this restricts how data flows through connectors, preventing unauthorised data movement). If a tenant on the top floor tries to bring a barbecue grill into the lift, the building manager stops it — that is a data policy enforcement.

Each floor has its own key card access (role-based security). The ground floor is open to all employees, the first floor is only for testers, and the top floor is restricted to the party hosts (system administrators and power users). If you try to use the lift from the top floor directly to the ground floor with a full data set, the building's policy might block that move entirely. This is why you need separate environments: to prevent a broken coffee table (a buggy app) from ruining the actual party, and to ensure data only moves where the rules allow.

## Core explanation

Let's start by defining environments. An environment in Microsoft Power Platform is a container that holds all your apps, flows, connections, and data sources. Think of it as a sealed plastic tub in your fridge: one tub might hold leftovers from last night's dinner (your test data), another tub holds fresh vegetables for the weekend (your production data). If you mix them up, you could eat spoiled food or serve raw chicken to guests. Environments keep your work organised and safe.

There are three main types of environments you need to know for PL-900: Sandbox, Production, and Default.

- Sandbox environment: This is a non-production space for development and testing. You can break things here without consequences. For example, you can build a new app, add experimental logic, or try out a new connector — and if it fails, nobody outside your team cares. Sandboxes are often used by developers to write code, test flows in Power Automate, or prototype chatbots in Power Virtual Agents.

- Production environment: This is the live environment where real users interact with your apps. It contains real data from your organisation's systems. Any change here can affect actual business operations, so you should never test directly in Production. For PL-900, remember that Production environments require a Power Apps per user plan or per app plan license to access.

- Default environment: Every tenant (your company's account in Microsoft 365) gets one default environment automatically. It is created for you and contains all the apps shared with everyone in your organisation. The default environment is like the shared kitchen in an office — anyone with a key can walk in and use the equipment, but no single person controls it entirely. You cannot delete the default environment, but you can control who has access to it.

Each environment also has a type called 'trial environment' that lasts 30 days and is used for short-term testing or learning. Microsoft automatically deletes trial environments after the period ends, so never put important data there.

Now, let's talk about data policies. A data policy is a set of rules that control how data moves between connectors in Power Platform. Connectors are the bridges that link your apps to external services like SharePoint, Salesforce, or Twitter. Microsoft groups connectors into three data groups: Business data only, Business and non-business data, and Non-business data only.

When you create a data policy, you decide which connectors can be used together in the same app or flow. For example, you might create a policy that says: 'You can use the SharePoint connector and the SQL Server connector together (both are Business data), but you cannot use the Twitter connector with the SharePoint connector (because Twitter is Non-business data and SharePoint is Business data)’. This prevents a flow from pulling a customer's email from Salesforce and posting it to a public Twitter feed — a major compliance violation.

In the exam, you need to know that data policies are set at the environment level or at the tenant level (applied to all environments). You also need to understand that data policies affect Power Automate flows, Power Apps, and Power Virtual Agents chatbots. If a policy blocks a connector combination, the app or flow simply will not run when that combination is attempted.

The reason these concepts exist is to replace the old way of managing data security: trusting individual developers to 'be careful' — which never works. Instead, environments and data policies give administrators central control. They ensure that a junior developer cannot accidentally expose your customer list on a public website, and that a test app cannot corrupt your live sales database.

## Real-world context

Imagine you work for 'HealthyBites', a meal-kit delivery company with 500 employees. You have been asked to help set up Power Platform for the sales team. Here is what an IT professional (maybe you!) actually does step by step.

First, you log in to the Power Platform admin centre (admin.powerplatform.microsoft.com). You see a list of environments. Your company already has one default environment, but that is not enough. The sales team needs a safe space to test a new app that calculates delivery fees based on customer postcodes.

You create a new sandbox environment called 'Sales - Dev'. You click 'New', give it a name, choose 'Sandbox' as the type, and select a region (e.g., UK South because your company is based in London). You also assign a security group (only members of the 'Sales Developers' group can access this environment). This is critical: without this step, any employee could accidentally stumble into the development work and mess it up.

Next, you create a production environment called 'Sales - Prod'. This environment will host the final app that the entire sales team uses daily. You assign the 'Sales Users' security group to this environment. You also note that production environments require a Power Apps license for each user — so you coordinate with the licensing team to purchase 50 per-user plans.

Now, data policies. Your company's compliance officer says: 'We cannot let our delivery fee calculator send customer postcodes to any social media site or public cloud storage.' You navigate to the 'Data Policies' section in the admin centre. You create a new policy called 'Sales Data Protection'. You select the environment 'Sales - Prod'. Then you classify connectors: SharePoint (Business data), Salesforce (Business data), Twitter (Non-business data), Dropbox (Non-business data). You then define the policy rule: 'Business data connectors cannot be used in the same app with Non-business data connectors.' You save the policy.

You test this: you ask a developer to build a flow that writes a customer's postcode to a Dropbox file. The flow fails to run. The error message says: 'This flow cannot run because of data policy restrictions.' The developer learns they must use a business-approved connector like SharePoint instead.

Finally, you monitor the environment. Every week, you check the 'Analytics' tab in the admin centre to see how many apps are running and whether any users are hitting data policy violations. If you see a spike in violations, you investigate: is a user accidentally trying to connect a non-business connector? You then adjust the policy or educate the user.

This step-by-step process is exactly what a Power Platform administrator does in real companies. You are not writing code — you are setting up the rooms (environments) and the rules (data policies) so that everyone else can build safely.

## Exam focus

The PL-900 exam loves testing 'Managing Environments and Data Policies' because it is a core concept that beginners mix up constantly. Here is what you need to focus on.

First, memorise the three environment types and their purposes. The exam will give you a scenario: 'A developer wants to test a new Power Automate flow without affecting other users. Which environment type should they use?' The answer is Sandbox. They will also ask: 'Which environment type cannot be deleted?' The answer is Default. They will try to trick you by saying 'Production' or 'Trial' — do not fall for it.

Second, understand data groups. The exam presents three categories: Business data only, Business and non-business data, and Non-business data only. For example, they might ask: 'A company wants to prevent customer data from being exported to a personal Google Drive. Which data group classification should they use for Google Drive?' The correct answer is 'Non-business data' — because you then create a policy that blocks mixing Business and Non-business data.

Third, know the scope of data policies. A data policy can be applied to a single environment or to the entire tenant (all environments). The exam loves to ask: 'Where can you set a data policy that applies to all environments?' Answer: Tenant level. They might mislead you by saying 'Environment level' or 'User level'.

Fourth, remember that data policies affect Power Automate, Power Apps, and Power Virtual Agents. The exam will include a question like: 'A user's chatbot cannot post a message to Twitter. What is the most likely cause?' Answer: A data policy blocking the Twitter connector.

Fifth, be ready for questions about environment creation. Know that you need the Global Admin or Power Platform Admin role to create environments. The exam might ask: 'Which role is required to create a new production environment?' Answer: Power Platform Administrator.

Sixth, understand the concept of 'environment lifecycle'. Environments can be created, copied, reset, and deleted (except the default). The exam tests that copying an environment creates a duplicate of all apps and flows, but not the actual data in data sources — they want you to know that copy includes configurations, not live data.

Finally, watch out for confusing terms. 'Environment' and 'Tenant' are not the same. A tenant is your company's entire Microsoft 365 organisation; an environment is a container inside that tenant. The exam tries to make you think they are the same thing.

Key definitions to memorise on the exam:
- Environment: A container for apps, flows, connectors, and data sources.
- Sandbox: Non-production environment for development and testing.
- Production: Live environment for real users.
- Default: Automatically created environment that cannot be deleted.
- Data policy: Rules controlling connector combinations.
- Data groups: Business data, Non-business data, and the mixed group.
- Tenant: Your company's Microsoft 365 organisation.

## Step by step

1. **Plan your environment strategy** — Before creating any environments, you decide how many you need and what type. For example, a small company might need one sandbox for development, one production environment for live apps, and rely on the default environment for shared organisation-wide apps. This planning prevents creating unnecessary environments that cost money or confuse users.
2. **Create the sandbox environment** — You log in to the Power Platform admin centre, click 'Environments', then 'New'. You choose 'Sandbox' as the type, give it a name (e.g., 'Sales Dev'), select a region (e.g., UK South), and assign a security group (e.g., 'Sales Developers'). This ensures only the development team can access it, keeping test work separate from live operations.
3. **Create the production environment** — You repeat the creation process but choose 'Production' as the type. You name it (e.g., 'Sales Prod'), assign a different security group (e.g., 'Sales Users'), and note that you need licenses for each user who will access this environment. This environment is now locked down for live use only.
4. **Define and apply a data policy** — In the admin centre, navigate to 'Data Policies'. Click 'New policy'. Give it a name (e.g., 'Customer Data Protection'). Choose the environment(s) it applies to (e.g., 'Sales Prod'). Then classify connectors: mark SharePoint, Salesforce, SQL Server as Business data; mark Twitter, Dropbox, Gmail as Non-business data. Finally, select the rule: 'Prevent Business data connectors from being used with Non-business data connectors'. Save the policy.
5. **Test the data policy** — Ask a developer to create a simple Power Automate flow that uses the SharePoint connector and the Dropbox connector in the same flow. When they try to save or run it, the system displays an error about a data policy violation. This confirms the policy is active. If the flow uses only Business connectors (SharePoint and SQL Server), it runs successfully.
6. **Monitor and adjust environments and policies** — Regularly check the 'Analytics' tab in the admin centre to see environment usage and any policy violations. If you see repeated violations from a specific user, you might educate them or adjust the policy if it is too restrictive. You might also create additional environments as your company grows — for example, a separate 'HR Prod' environment for human resources apps.

## Comparisons

### Sandbox Environment vs Production Environment

**Sandbox Environment:**
- Used for development and testing — safe to break things.
- No license required for developers to create apps (within limits).
- Can be reset or deleted without affecting real users.

**Production Environment:**
- Used for live business operations — changes affect real users.
- Each user requires a per user or per app license to access apps.
- Should never be reset or deleted without careful backup planning.

### Default Environment vs Sandbox Environment

**Default Environment:**
- Created automatically for every tenant and cannot be deleted.
- Contains apps shared with everyone in the organisation by default.
- Cannot be renamed or converted to another type.

**Sandbox Environment:**
- Created manually by an administrator when needed.
- Contains only apps for the specific development group assigned.
- Can be renamed, reset, or deleted (if no longer needed).

### Data Policy at Tenant Level vs Data Policy at Environment Level

**Data Policy at Tenant Level:**
- Applies to all environments in the tenant automatically.
- Cannot be overridden by environment-level policies (takes precedence).
- Used for company-wide compliance rules (e.g., block all social media connectors).

**Data Policy at Environment Level:**
- Applies only to the specific environment you set it on.
- Can be overridden by a more restrictive tenant-level policy.
- Used for department-specific rules (e.g., block Dropbox only for the Sales environment).

### Business Data Group vs Non-Business Data Group

**Business Data Group:**
- Includes connectors like SharePoint, Salesforce, SQL Server.
- Used for internal or trusted systems where company data resides.
- Cannot be combined with Non-business connectors when policy blocks mixing.

**Non-Business Data Group:**
- Includes connectors like Twitter, Dropbox, Gmail, Facebook.
- Used for personal or public services outside company control.
- Cannot be combined with Business connectors when policy blocks mixing.

### Creating an Environment (Sandbox) vs Copying an Environment (Sandbox)

**Creating an Environment (Sandbox):**
- Creates a brand new, empty environment with no apps or data.
- You must build or import apps from scratch after creation.
- Does not consume extra storage beyond the new environment's base allocation.

**Copying an Environment (Sandbox):**
- Duplicates an existing environment's apps, flows, and configurations.
- Copies all solution components but not actual data in data sources.
- Consumes storage equal to the source environment's configuration size.

## Diagram

_This diagram shows how a tenant contains a default, sandbox, and production environment, each holding different types of apps, and how a data policy classifies connectors into business and non-business groups to prevent mixing them._

```mermaid
graph TD
    A[Tenant] --> B[Default Environment]
    A --> C[Sandbox Environment]
    A --> D[Production Environment]
    B --> E[Shared Organisation Apps]
    C --> F[Dev & Test Apps]
    D --> G[Live Business Apps]
    H[Data Policy] --> I[Business Data Group]
    H --> J[Non-Business Data Group]
    I --> K[SharePoint, Salesforce, SQL Server]
    J --> L[Twitter, Dropbox, Gmail]
    C --> M[Policy Blocks Mix of I and J]
    D --> M
```

## Common misconceptions

- **Misconception:** The default environment is just like any other environment and can be deleted if I do not want it. **Reality:** The default environment is created automatically by Microsoft and cannot be deleted. It is tied to your tenant and is used for organisation-wide apps. You can restrict access but never remove it. (New users see the word 'default' and assume it is optional or temporary, like a default printer setting. But in Power Platform, it is a permanent fixture.)
- **Misconception:** Data policies apply only to Power Automate flows, not to Power Apps. **Reality:** Data policies apply to Power Automate, Power Apps, and Power Virtual Agents chatbots equally. If a Power App tries to use a blocked connector combination, it will fail at runtime. (Many beginners start with Power Automate and think data policies are a 'flow thing'. But Microsoft designed them to protect all low-code tools under the same umbrella.)
- **Misconception:** A production environment requires no special license — anyone can just use it. **Reality:** To use a production environment, each user needs a Power Apps per user plan or per app plan license, or a Power Automate license depending on what they are running. Sandbox environments often include free developer credits. (The word 'production' sounds like it is just about where the app runs, but Microsoft ties licensing to environment types. Beginners forget that 'production' equals 'paid license required'.)
- **Misconception:** Data policies control what data is stored, so they can block specific columns in a database. **Reality:** Data policies control which connectors can be used together in an app or flow. They do not filter data at the column level. They block entire connector categories (e.g., 'you cannot mix Twitter and SharePoint'). (The word 'data policy' sounds like fine-grained data governance (like GDPR rules about what fields you can read). But in Power Platform, it is a coarse-grained connector grouping rule.)
- **Misconception:** You can copy an environment including all its actual data (like rows in a database) to another environment. **Reality:** Copying an environment duplicates the apps, flows, connections, and configuration — but it does not copy the actual data stored in external data sources like SQL Server tables or SharePoint lists. You would need to export and import data separately. (The word 'copy' in everyday language means everything gets duplicated. But Microsoft's environment copy is a configuration copy only, for security reasons (so you do not accidentally duplicate sensitive customer data).)

## Key takeaways

- Environments are containers that separate development work from live production work, preventing accidental data corruption.
- The default environment is created automatically for every tenant and cannot be deleted, only managed.
- Data policies block specific connector combinations to stop sensitive business data from flowing into public or non-approved services.
- Data policies apply to Power Automate, Power Apps, and Power Virtual Agents — not just to flows.
- To create or manage environments, you need the Global Admin or Power Platform Admin role in your Microsoft 365 tenant.
- A production environment requires users to have a Power Apps or Power Automate license, while sandbox environments often include free development rights.
- Data policies can be set at the environment level (for one environment) or at the tenant level (for all environments in your organisation).

## FAQ

**How many environments can I create in Power Platform?**

There is no hard limit on the number of environments, but each environment uses storage (database capacity) that your tenant has available. Microsoft gives you a default storage limit per tenant, so you can create environments until you run out of allocated storage.

**Can I restore a deleted environment?**

No, once an environment is deleted, it is gone permanently — including all apps and flows inside it. The only exception is that Microsoft retains deleted environments for 7 days in a soft-delete state, but as a beginner you should never rely on that. Always keep backups by exporting your solutions.

**Do data policies apply to connectors used in Power BI?**

No, data policies in the Power Platform admin centre only apply to Power Automate, Power Apps, and Power Virtual Agents. Power BI has its own separate set of data governance rules called 'Data Policies' in Power BI service settings.

**What happens if I set a data policy at the tenant level and also at the environment level?**

Both policies apply. The most restrictive policy wins. For example, if the tenant level policy blocks Twitter and the environment level allows it, the environment level is overridden by the tenant policy. This is because tenant policies are designed to be the highest level of enforcement.

**Can I change the type of an environment later (e.g., from Sandbox to Production)?**

No, once you create an environment with a specific type (Sandbox, Production, Default), you cannot change its type. You would need to create a new environment of the desired type and move your apps manually or by exporting/importing solutions.

**Why does my data policy keep blocking my flow even though I only use one connector?**

Data policies block combinations of connectors, not single connectors. But if you are using a connector that is classified as 'Non-business data' and the environment's policy only allows 'Business data only' group, then even a single Non-business connector is blocked. Check the data group classification of your connector.

## Check your understanding

1. **Which environment type is automatically created for every tenant and cannot be deleted?**

   Answer: The default environment is created automatically and cannot be deleted, only managed.

2. **What is the main purpose of a data policy in Power Platform?**

   Answer: A data policy controls which connectors can be used together in an app or flow, preventing sensitive business data from being sent to non-business services like Twitter or Dropbox.

3. **Can a user access a production environment without a license?**

   Answer: No, to access apps in a production environment, each user needs a Power Apps per user plan or per app plan license (or a Power Automate license for flows).

4. **Where do data policies apply — only to Power Automate, or to other Power Platform components too?**

   Answer: Data policies apply to Power Automate, Power Apps, and Power Virtual Agents, not just to flows.

5. **What happens if a tenant-level data policy conflicts with an environment-level data policy?**

   Answer: The tenant-level policy takes precedence because it is the highest level of enforcement, and the more restrictive rule applies.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/pl-900/power-platform-environments