Introduction
The Power Platform in M365, as the name suggests, is incredibly powerful. It is capable of developing applications to meet almost any business need and can often be developed by users with little to no developer background.
It is precisely for this reason that the Power Platform needs to be carefully governed. Without some level of oversight, the usage of Power Apps, Power Automate, and potentially even Power BI, Power Virtual Agents, and the Microsoft Dataverse can grow beyond any useful level and become an impossibility to manage.
Much of this information extends, supports, or runs parallel to Microsoft Best Practice, outlined here:
Admin and governance best practices – Microsoft Power Platform – Power Platform | Microsoft Docs
Tenant and Licensing Configuration
Most products within the platform work on a ‘Freemium’ model. Assuming you are running on an E3 or similar license, Power BI, Power Automate, and Power Apps ‘Free’ licenses are all included. This gives users the following capabilities:
- Power BI: Create a personal workspace, connect to data, publish to the personal workspace.
- Power Automate: Create unlimited Flows with all non-premium connectors. Actions will drawdown on a shared ‘Action Pool’, which when consumed will throttle/stop ALL flows in the environment.
- Power Apps: Create unlimited Canvas apps with all non-premium connectors. No limitation to sharing or publishing.
- Power Virtual Agents: There is currently no ‘Free’ license to Power Virtual Agents.
Given the significant capability outlined above, it is recommended to have a strategy for the education and assignment of ‘Free’ licenses. This should be extremely simple, only introducing users to the core concepts required to responsibly build solutions using the platforms. An automated process to assign these licenses is recommended.
Many of the license options for the Power Platform are not ‘Per-User’ licensing, but instead ‘Per-App’. For example, a single ‘Portal’ Power App may be purchased. The assignment process for these licenses is somewhat limited, and as such, it is strongly recommended that the ‘Environment Configuration’ (below) is performed before users begin using the platform.
Environment Configuration
Within the Power Platform, ‘Environments’ exist that act as a parent container to the many different types of assets that can be created. Most organisations have a single ‘Default’ instance, created with their tenancy, that all users can create apps within.
Per-app licenses, when procured, can be assigned to a single environment, after which it is consumed as required by any user within that environment. To therefore facilitate responsible consumption of licenses, it is recommended that at the very least a ‘Premium’ environment is provisioned and only users that can be trusted to responsibly consume premium capabilities are granted access to this environment. These may be your internal development team, a team of specifically trained business users, or anything else.
It is also recommended that at least one ‘Development’ or ‘Sandpit’ environment is created, as a location where developers can create and experiment with an explicit ‘No support provided’ provision.
Once a ‘Premium’ and ‘Development/Sandpit’ environment is created, service levels can be defined for each of the different environments. The following is an example of how the different environments may be managed. Finding the right balance for your organisation, including provisioning additional environments if necessary, is key to getting your governance correct:
- ‘Default’ Environment
All users have access. Audits are performed once per week, with all new apps/assets classified and given a ‘Business Owner’ and ‘Support Level Required’. Allow for ‘Sandpit/Development’ apps in here, but delete them after a short period of no usage. No critical business applications are permitted (These need to go into the ‘Premium’ environment).
- ‘Premium’ environment
Only identified ‘Premium’ users have access. Nothing is created without prior approval, including support agreements and SLAs. No ‘Sandpit/Development’ applications permitted. A naming convention here will improve readability for all other developers in the environment. - ‘Sandpit/Development’ environment
Identical membership to ‘Premium’ environment. No restriction to creation or consumption, but explicitly no support is given. Quarterly audits to ensure no assets are being used for business purposes.
To best manage these environments, it is recommended to have a register of all applications including extended metadata (I.E Classification, owner, SLA, etc). This can be built using a SharePoint list and can be self-managed using Power Apps and Power Automate. There are a significant and growing number of Power Platform Administration connectors available within the Power Platform.
Expanded Capacity
The core of each component of the Power Platform is strong in itself and enhanced immediately with a ‘Premium’ license. In addition to this functionality, many features require specific licensing or configuration. These include:
- Desktop Flows (“UI Flows” or “Robotic Process Automation”)
These require a premium license that includes the ability to execute these, as well as installing and managing an ‘On-Premises Data Gateway’ to the machine that will execute them.
Introduction to Power Automate Desktop – Power Automate | Microsoft Docs - AI Models
Allowing for classification, entity extraction, smart form processing, object detection, prediction, and more. These require an ‘AI Builder’ license
What is AI Builder? – AI Builder | Microsoft Docs - Portal Apps
Portal Apps allow for anonymous or alternative authentication methods to be used for a public-facing Power App. Using these requires dedicated Portal capacity, which is charged on a consumption basis.
What is Power Apps portals? – Power Apps | Microsoft Docs - Component Library
Software Development Lifecycle/Application Lifecycle Management
Core SDLC/ALM principles are not built into the Power Platform by default and can be quite difficult to configure. Especially given some of the core strength of the platform is the ability for business users to solve their own problems, applying a comprehensive SDLC across all assets can be extremely difficult.
To provide some level of solution management when a single problem is being solved using multiple Power Platform assets, a ‘Solution’ should be created. This will also allow for easier translation between environments, and much stricter version control. Management of Solutions is also the only way that some Power Platform components can depend on each other. For example, a Flow can only call another Flow if they are a part of the same solution. Some license models may also consider a ‘Solution’ to be a single ‘App’, rather than each discrete Power App/Flow. Putting assets into solutions is therefore important not only for ALM but for reducing licensing expenditure.
It is recommended that when specific development projects take advantage of the Power Platform, that they use the Power Platform Build Tools for Azure DevOps. These will allow the powerful capability of build and release pipelines, including the process associated with them, to be used for the publishing of Power Platform solutions.
Microsoft Power Platform Build Tools for Azure DevOps – Power Platform | Microsoft Docs
There is a significant capability to extend the capabilities of the Power Platform, including custom connectors, component libraries, and integration with other technologies.
Power Automate for enterprise developers, ISVs, and partners – Power Automate | Microsoft Docs
Power Apps for enterprise developers, partners, and ISVs – Power Apps | Microsoft Docs
