The Rise of Power Platform
Low-code and no-code solutions have been popular since computers were invented. John Backus, the genius who invented the FORTRAN language, thought it would make computer programming accessible to non-programmers (and he was right!) Since then, we’ve had BASIC, Visual Basic, FoxPro, Lotus Notes, and a number of other platforms that promised easy drag-and-drop assembly of business-quality solutions.
With that background, you can see what market niche Microsoft is trying to fill with Power Platform. It’s intended to let mere mortals build business applications without requiring a computer science degree or a direct line to the overworked IT department.
The platform consists of four main components that work together like a well-oiled machine: Power Apps for building custom applications, Power Automate for workflow automation, Power BI for data visualization and analytics, Power Pages for data-driven webpage building, and Copilot Studio. These tools collectively are intended to let ordinary business users build useful applications that take advantage of data held in Dataverse or Dynamics 365, as well as the features in Teams, SharePoint, and OneDrive. Each of these applications creates and consumes data from various parts of the Microsoft 365 ecosystem, and honors the access and governance controls (like sensitivity labels) that you put in place.
Environments and Tenants
You’re already familiar with the idea that the tenant is the essential security boundary for Microsoft 365 (although multi-tenant organizations and guest users blur this boundary a bit). There’s one set of settings per tenant, one set of Teams policies, and so on.
By default, your Microsoft 365 tenant will have a single Power Platform environment (cleverly called the “default environment.”) In Power Platform, an environment essentially is a container that holds various Power Platform components. Microsoft’s documentation summarizes environments thusly:
Each environment is created under a Microsoft Entra tenant, and its resources can only be accessed by users within that tenant. An environment is also bound to a geographic location, like the United States. When you create an app in an environment, that app is routed only to datacenters in that geographic location. Any items that you create in that environment (including chatbots, connections, gateways, flows using Microsoft Power Automate, and more) are also bound to their environment’s location.
What we learn from that is that your Entra tenant may contain multiple environments but they may be geographically separated, and they are logically separated as well. Every environment has its own group of settings, including security permissions. Each environment may contain its own set of apps, flows, data connections, and security settings, operating as an isolated container that keeps your development work separate from production systems.
Microsoft allows you to create multiple environments within a single Microsoft 365 tenant, and there are good reasons to do so.
Why Use Environmental Isolation?
One common reason to use multiple environments is that you can dedicate environments for specific functions. For example, it is common, and good, practice to have one environment for development use, a separate environment for testing, and a third environment for production. As developers make changes in the development environment, they can deploy and modify their flows, applications, and so on, without the possibility of any bad impact on the production environment. There are many possible variations of this arrangement. For example, one large automaker that I work with has four environments: development, testing, and production, plus a separate environment just for users to create their own Power Automate flows. The three “real” environments are managed by the IT team and backed up regularly; the user-flow environment is more or less a jungle where there is little support available, by design.
Three Simple Tasks to Make Your Life Easier
No matter your adoption plans for Power Platform, there are three things you should plan to do. These tasks are “simple” in the sense that they are easy to explain; the actual work of implementing them may be complex or time-consuming, depending on your organization’s politics and technology. If your organization isn’t using Power Platform much yet, that’s great! You’ll have some headroom to take these three steps. If you’re already well down the Power Platform path, these may be more complicated.
First, create a clear environment strategy before your users start spinning up environments like they’re ordering pizza. Define naming conventions, determine who gets which type of environment access, and establish approval processes for new environments. Microsoft’s Power Platform Center of Excellence (CoE) has a toolkit that, among other features, includes a solution to allow users to request new environments so that you can approve or deny the requests. If you don’t do this (and it may already be too late), you’ll end up with environment sprawl, which just means you’ll have more cleanup to do later.
Second, immediately deploy Power Platform Data Loss Prevention (DLP) policies. These policies allow you to restrict the flow of data through connectors, so you can specify that particular data sources are either forbidden, allowed everywhere, or allowed conditionally, from day one. Think of DLP as the digital equivalent of the safety interlocks that prevent you from running your microwave oven with the door open—DLP can prevent users from accidentally creating a flow that dumps your customer database to their personal Dropbox.
Third, dig into the application lifecycle management world to understand how to monitor and manage your environments. Knowing which flows, applications, and bots are in use, in which environments, and by whom, is critical to ensuring that your data and systems remain secure. Good ALM practices will also help you when, as is inevitable, a user-developed app or bot becomes so important to the business that you’re asked to formally support it.
Microsoft’s documentation on application lifecycle management (ALM) explains more about how to set up development-focused environments and how to monitor and manage them, but the best way to gain familiarity with these solutions is to jump in, install the CoE tools, and start experimenting. As you get more experience with Power Platform management, you’ll be better able to identify what your specific organization needs in terms of protection, governance, and data and application management.
