Power Platform Environments - Simply Explained

0:00 Your tenant gets one default environment and every licensed user can build inside it. That is also the environment Microsoft says not to run production work in. Welcome to the M365 FM podcast, where we explore the people, ideas, and technologies shaping the future of work. Today we're talking about power platform environments and why the container you build in decides what your app can do. Each environment keeps its own data, and apps can't reach across that line. By the end, you'll know which environment to reach for and why. What an environment actually is. A power platform environment is a space where your business data, your apps, your chatbots and your flows all live together. Microsoft built it as a container, and the job of a container is to keep things apart that don't belong together. Everything you create inside it, from a simple canvas app to an automated flow, stays attached to that environment for its whole life.

0:45 Think about how your company stores documents. You wouldn't throw every file from every team into one shared folder and hand the whole company the same key. Yet that's exactly what a single shared workspace does to your apps. An environment exists, so you never have to work that way, and it separates apps that have different roles, different security needs, or different audiences. This matters more as a company grows. One shared space works fine for a handful of small tools, and then it doesn't. A change for one team can ripple into another. Team's work environments give you a way to keep those worlds separate on purpose, so a small experiment in one corner won't quietly break something in another. You can see the idea in how teams actually use them. One organization gives each department its own environment, so marketing's data never mixes with finances.

1:26 Another runs a production environment for the apps everyone uses, with a sandbox sitting beside it for the changes nobody should see yet. Microsoft even suggests separate environments for different global branches of a company, which tells you how central this idea is. Every environment also sits inside your Microsoft Entra Tenant, which is the directory that holds your company's users and groups. Only people inside that tenant can reach the environment's resources, so an outsider can't wander in. The environment is bound to a region, to anything you build there, including connections, gateways, and flows, runs in data centers near that location. There's one rule that catches almost everyone An app can only connect to data sources that live in the same environment. If you build an app in one environment and the data sits in another, the app can't see it. No matter how correct your logic looks.

2:07 That single restriction explains a lot of beginner frustration. A broken connection often looks like a bug when it's really a boundary doing its job. It's a real boundary that decides where your app lives and what it can reach. And it isn't a label you attach to a project at the end. Once that idea clicks, the rest of power platform starts to feel less random. The next question is which kind of environment you should actually be in. The environment types in plain words, environments come in a few types and the type tells you what the space is for. You don't need to memorize the whole list, because you only need to recognize which one you're standing in. By the end of this section, you'll be able to name it. The first one you meet is the default environment. Every tenant gets exactly one. Microsoft creates it for you, and anyone with a license can start building their new users are dropped straight into the maker role, so they can start creating apps on day one.

2:51 That's why the default feels welcoming, and it's also why it fills up so fast that convenience has a cost. The default environment is shared with your whole company. It can't be deleted, and Microsoft gives it no backup guarantees. It's meant for experiments and small personal tools, not for the apps your business depends on. It also has a ceiling of one terabyte, and it opens with a small slice of that spread across its database. Its files and its logs. Remember that shared no backup default because it comes back in the habits we'll cover at the end. Production is the opposite, and it's the environment you depend on. Permanent work lives there, and the apps people use every day should run there. If something has to stay up, it belongs in a production environment. Sandbox environments are the safe rooms. A sandbox is any non-production environment, and it comes with abilities that would be reckless in production, like resetting, copying and deleting.

3:37 That's the point, because you want to break things in a sandbox and never in production. Developer environments are personal. A developer environment belongs to one person, and it's meant for building and testing rather than for running or sharing production apps. Each user can have one managed developer environment, and it doesn't count against your company's capacity. If you're learning the platform, this is the space that's yours to mess up. Trial environments are short lived. You get one per user. It's built for quick tests and proofs of concept, and it expires after thirty days. When it's gone, it's gone. So don't park anything important there. One thing is worth knowing in plain words, the older kind of developer environment called unmanaged is being retired and so is the Dataverse for teams environment. The developer type still exists, but it now means a managed developer environment.

4:18 There's no need to panic about that. And you do need to know the names have shifted. Not every type is open to everyone either. An admin can restrict who is allowed to create sandbox trial and developer environments, so the choice isn't always yours to make. If a button is grayed out, that's usually why the names matter less than the purpose behind each one. You pick a default to experiment, a developer environment to build in private, a sandbox to test changes, and a production environment to serve the people who depend on you. That's the whole decision, and it's smaller than it first looks. Dataverse one database per environment. Every environment can have a database, and that database is called Dataverse. The rule around it surprises people. An environment can hold a single Dataverse database or no database at all, and it can never hold two.

4:58 That's the ceiling. And there's no version of the setup where you get a second one. Because of that rule, your data doesn't quietly flow between environments. Each one keeps its own database. So a copy of an environment can exist for testing without ever touching the real records. Microsoft even lets you copy a sandbox. That way, you can try a change against realistic data before it goes anywhere near a live app. Dataverse is also where your structure lives, meaning your tables, your columns, and the relationships between them. When you build a model driven app, that structure is the backbone. The app runs on. That's why Dataverse and environments get talked about together so often. A canvas app can reach plenty of other data sources, and a model driven app leans hard on Dataverse for its shape. So think of Dataverse as the filing cabinet that belongs to one room.

5:40 It holds the records for that room and nothing else, and it stays behind when you walk into a different one. That picture is simple, and it's accurate enough to keep you out of trouble. Who gets in and what they can touch. Environments have built in roles, and the two you'll hear most are environment admin and environment maker and environment admin runs the environment, can create its database and sets the guardrails. An environment maker can create apps, connections and flows, but has no rights to the data itself. That last part confuses people, so it's worth saying in a different way. Being allowed to build in an environment isn't the same as being allowed to read its data, and those are two separate doors. You can hold the key to the workshop and still not hold the key to the filing cabinet. Here's how that plays out. In practice, you might be able to open an app in the maker portal and still see empty screens.

6:25 The app is fine, and you're simply missing a security role on the data side. That mismatch is common, and it's the single biggest source of it. Works for my colleague, but not for me. Confusion. The rules also shift depending on whether the environment has a database without one. Environment, admin and environment maker are the only two roles that matter with one. The system administrator role takes the top spot. The list of predefined roles grows to include names like basic User and System Customizer, along with app specific roles that arrive when you add a product like dynamics three hundred sixty five. There are also bigger roles that live above any single environment. Tenant level admins like the Power Platform administrator or the global administrator manage the whole tenant. They don't automatically get access to the data inside a given environment.

7:07 In an environment with a database. Full admin access comes from the system administrator role, not from being a tenant admin. That surprises a lot of people and it's there on purpose. Then the Dataverse security roles decide what a person can see and change once they're inside. Names like System Administrator, System Customizer, and Basic User describe how much reach someone has. Microsoft's rule of thumb is to give each person the least access they need to do their job. A maker who needs to update tables usually needs the system customizer role on top of environment maker. That's why two roles are sometimes required for one job. Finally, security groups and licenses decide who can even see an environment in the first place. That's why a colleague can work at your company and still have no idea your app exists. Because access is granted on purpose and never by accident.

7:49 Environment groups. Folders for environments. As a company grows, the number of environments can climb into the hundreds and managing them one at a time stops working. Microsoft's answer is the environment Group, which it describes as a folder for your environments. A group collects related environments and applies the same rules to all of them at once. Only managed environments can join a group. Each environment can belong to just one group, and groups can't overlap or nest inside each other. Those limits keep the structure predictable, which is the whole point when you're trying to bring order to a sprawling setup. The useful part is what a rule actually does. When you publish a rule at the group level, that's setting locks inside every member environment, so a local admin can't quietly change it. Remove an environment from the group and it keeps the last settings it received.

8:31 Those settings unlock though, which lets someone manage it again. A group is also a natural home for similar spaces, and Microsoft's own examples show the range. One company keeps a personal productivity group for every maker's private space. Another builds a copilot pilot group, so AI features can be tested in sandboxes before anyone touches production. A global business splits its environments by region, so each one follows local rules. A careful team keeps a relaxed development group beside a stricter production group. Managed environments. The premium switch groups and rules only work on managed environments, so that phrase deserves a plain explanation. An environment is either managed or it isn't, and turning the managed switch on unlocks a set of premium capabilities aimed at admins.

9:12 Microsoft groups those capabilities into three ideas, which are more visibility, more control, and less effort. In practice, that means usage reports that show which apps people actually open and sharing limits. So a maker can't send an app to the entire company. It also means solution checking before a change goes live, and extended backups that stretch from seven days to twenty eight. None of this is something a beginner switches on, and that's fine. The reason it matters is simpler than the feature list, because it explains why a setting you expect it to change is locked. If an environment is managed and a rule covers that setting. The answer is that someone at the group level owns it now. Managed environments also let an admin root new makers into a personal environment and govern it automatically. That's how a company scales from a handful of environments to hundreds without losing control of any of them.

9:53 Moving work safely. Arm and solutions environments hold your work, but work still has to move. And that movement is where things get interesting. The practice of managing an app through development, then testing, then production is called application lifecycle management or ARM environments are the containers in this picture and solutions are the boxes. You move the pieces in. A solution packages your apps and components so they can travel from one environment to another. Here's the detail that matters. A solution carries the structure of your app and not your business data, so your records stay behind in their own environment. Solutions come in two flavors and the names are almost too simple. You edit an unmanaged solution while you're building and it lives in your development space. You ship a managed solution, and that's the version that belongs in a test, acceptance or production environment.

10:36 Microsoft's guidance is that production should hold managed solutions, ideally ones built by an automated process rather than assembled by hand. The flow, then, is short and repeatable. You build in a development or sandbox environment, you test the change and you promote a managed solution to production. Nobody edits the live app directly, which is exactly how you avoid breaking the thing people depend on. Managed solutions also behave well when it's time to update. You can upgrade or remove one cleanly without dragging down the other solutions that share the same environment. That's exactly what you want. When several teams ship side by side, two ideas sit underneath all of this. The first is source control, where each solution source code is stored and tracked so changes can be reviewed and undone. The second is pipelines, a power platform feature that gives makers a simple path to push an app from development to test, and then to production.

11:23 That removes the need to hand carry files between environments, data, policies, the guardrails. There's one more layer, and this one keeps data from leaking where it shouldn't. A data policy is a guardrail that lowers the risk of someone accidentally exposing company data, and it works by controlling connectors. A connector is the bridge your app uses to reach another service, like SharePoint, outlook or teams. A data policy source connectors into three groups business, non-business and blocked and the rule underneath is elegant. Connectors in the same group can share data and connectors in different groups can't. That's what stops a personal account from quietly pulling from a business system. Some connectors can't be blocked at all because too much depends on them. Data versus one and so are SharePoint, outlook and teams.

12:06 A policy change also isn't instant since it has to reach every environment and every resource inside them. In most cases, it takes effect within the hour, and in the heaviest cases, it can take up to a day. The default setting matters too. When an admin creates a new policy, every connector starts out in the non-business group and they move the ones that belong elsewhere. That default is deliberate, because it's safer to loosen a rule on purpose than to discover one was never tight. A data policy bites in two different places at design time, when someone is building a blocked connector, simply can't be saved into a new app or flow at runtime. When an app is running or a flow fires on a schedule, a blocked connection fails. It shows up as a broken step that needs attention. A policy change can even suspend or quarantine a resource that breaks the rules, which is why admins think twice before flipping a switch.

12:50 You don't set these up as a beginner and you don't need to. What matters is knowing they exist because they explain why a connector that worked yesterday can be blocked today. How to tell where you are. All of this sounds like a lot, so let's make it practical. If you're an admin, the full list lives in the Power Platform Admin Center under Manage then Environments. Each one shows its type, its region, and its current state. If you're a maker, know the name of the environment you're in before you start building, that name tells you its purpose. Many organizations now use environment routing, which quietly gives each maker their own personal developer environment instead of letting everyone pile into the default. That's a good thing because it means your first app lands in a space that's yours and not in the shared room the whole company can see.

13:31 When in doubt, ask which environment is meant for your work because guessing is how projects end up in the wrong place. Best practices in plain words. Let me pull this into a few habits you can actually use. The biggest one is to stop treating the default environment as your production home. Rename it until its name says what it is and keep it for quick personal experiments. From there, build in your own developer or sandbox environment and ship to a production environment that people depend on. Keep your sandbox for testing so you never test something risky against live data. Keep the tenant tidy as well by deleting the apps, flows, and environments you no longer use, and by sharing carefully rather than broadly. A clean tenant is easier for everyone to trust, including you.

14:12 There's also a habit that pays off for everyone around you. Tell people which environment you built in and why. A strategy nobody understands looks like a restriction, and a restriction people resent is one they'll work around. None of these habits require you to be an admin. They just keep your work from becoming someone else's clean up job. An environment is a container for your apps, your flows, your data, and your connections. Everyone holds at most a single database. The type you choose sets its purpose and roles, groups and policies keep it safe. Here's my question for you. The next time you open power platform, will you know which environment you're building in and whether it's the right one? Subscribe to M365 FM to master the tools and the mindset shaping the future of work.