Power Platform is Valuable to Microsoft 365 Tenants
For many years, Microsoft and other technology vendors have been attempting to democratize the ability to build solutions with low-code platforms and toolsets. These platforms allow users to develop software at a faster speed using less code, GUIs, and drag-and-drop style capabilities.
Microsoft’s Power Platform is a more recent low-code offering. Like previous experiences of democratised technology in organizations, tenant administrators need to pay close attention to Power Platform when it comes to governance and administration, to ensure makers using the toolset are empowered in a secure environment. In this context, “makers” are the people who create the low-code solutions, such as apps, flows, and Copilot agents.
According to Microsoft (FY25 Q3 results), Power Platform has over 56 million monthly active users. It’s likely that users in your organization want to adopt, or are adopting these tools already, so governance is key. This article highlights some of the key areas to explore in governing and administering the Power Platform.
Power Platform Admin Center
First, let’s explore the Power Platform Admin Center. This is an area Microsoft has invested heavily in recently. For organizations new to the platform, or not quite ready to embrace Power Platform yet, the admin center is a great way to get to grips with Power Platform and the controls available to manage the capabilities makers can use. There are a few key controls worth exploring here to create some important guardrails around the platform.
Power Platform provides makers with 1000+ out-of-the-box data connectors to build automations, apps, and agents with. From an administrator or security person’s perspective, it’s easy to understand the concerns that using connectors to access external data might raise. Data Loss Prevention (DLP) policies are one of the first key controls to implement. DLP ensures business data remains separate from non-business data, and certain connectors, such as the HTTP connector or perhaps social media data connectors, remain completely blocked without exception.
Power Platform administrators should consider tenant isolation. Tenant isolation prevents cross-tenant communication for Entra ID secured scenarios for connectors in Power Platform. Enabling tenant isolation prevents a business user from creating application logic using low-code building blocks where authenticated connections use credentials from another tenant. Without tenant-isolation enabled, a user could send SharePoint data from a site they have access to in their organization to a site in another organization, for example.
The control for tenant isolation is under Security, Identity and Access in the Power Platform Admin Center. You can completely block cross-tenant communication and also allow list-specific domains. This is a key control to ensuring the reduced risk of data exfiltration from your organization.
Environments in Power Platform provide a facility for controlled groupings of solutions builds where access control and several settings are applied to those nested solutions. An additional control to explore in the Power Platform admin center is the setting controlling who can create and manage production environments. Environment security groups allow administrators to manage access control to environments with Entra ID security groups. The use of Entra ID security groups here allows for organizations to mirror existing access management processes used in the tenant, such as with the use of PIM or custom automation for managing time-controlled access.
When it comes to scaling up and becoming more mature in your use of the platform, the next step is to explore Managed Environments, provided you’re willing to make the licensing investment in the platform. With Managed Environments comes the ability to use Environment Groups, where you can group environments and set rules and settings across them all. This prevents system administrators for those environments from changing the settings that can be controlled at the group level. Preventing people from changing settings, like those governing the opt-in for generative AI features, can be critical to achieve compliance in some scenarios, such as ones where data should not move outside of the EU data boundary, while some services require movement to the United States geography.
Microsoft Purview
Microsoft Purview ingests audit events created by Power Platform for user actions, both from a maker standpoint and an end-application user standpoint. From a Power Apps perspective, audit events are logged for actions such as a maker creating an app or completing other app-level activities.
Power Platform also audits user activities, such as a user opening an app and authenticating against the APIs used by the app, and giving consent for connections that are used. Power Platform doesn’t however, audit user-level activities for end applications that makers have built out-of-the-box. In this scenario, while we might want to enable makers to build apps or automations that send emails, we should observe scenarios like this, using the audits for this API consent activity. For example, when a very senior or risky stakeholder in the business consents to an application with the Outlook connector, we should observe these patterns where applications could use dark patterns in their UX to hide the maker-developed action that will be taken with the context of that user.
It is worth keeping in mind that when makers build applications using Power Apps, the users of those applications won’t have the activities they take within them audited by Power Apps out-of-the-box. Telemetry can be logged to tools such as Application Insights separately, through which there is logic that the maker must implement. Where a background service, such as Exchange audits any relevant activity, this is respected.
Power Platform captures audit records for user interactions performed using Copilot agents, as well as maker activities in Copilot Studio, where makers build agents. Copilot Studio is the low-code capability in the Power Platform for building AI agents for Microsoft 365 and B2C scenarios.
To get more familiar with the Microsoft Purview audit events captured by the Power Platform, check out the documentation here or go to the Microsoft Purview portal to use the Audit solution to explore the Power Platform activities available there.
Purview Audit is more focused on observability and doesn’t implement any guardrail-type controls to stop people from doing silly things. However, having a rich store of audit events generated by Power Platform means that administrators can discover what people do with the platform. With that knowledge, administrators can achieve more of a balance between the enablement of makers by not switching everything off and ensuring compliance by mitigating observed risks.
Power Platform API
The next thing for Power Platform administrators preparing to operate the platform with a little more automation or potentially at a large scale is the Power Platform API. The caveat is that many of the endpoints available are in public preview. Assessing whether using the APIs is something worthwhile for an organization to invest in is gated by your requirements.
Some of the key endpoints to explore when looking at the API reference include the Environment Groups endpoints, licensing endpoints, and apps endpoints. Several samples and tools available for the Power Platform for inventory are available in the community. One of the things that baselines some of those is the API endpoint for Power Apps, which administrators can use to retrieve data on the apps in an environment. You can use the API to inventory applications makers are building and tie those assets into any existing processes your organisation might need to follow for asset management.
Managing licensing add-ons is already a tedious task for administrators working with Power Platform. Managing licensing and add-ons with an API will likely improve things with a carefully thought-out process implemented. The currency allocation endpoint allows for assignment of add-on licenses to environments, allowing this action to be automated in a request process, for example.
Finally, managing environments with environment groups can be done at scale more easily using the environment groups endpoints. So now, administrators can control settings at an environment group level for all associated environments and add environments to those groups using an endpoint to support a scaled process.
Summary
Power Platform is a great solution for organizations looking to gain benefits from enabling makers with low-code capabilities to solve business problems. However, use of the platform must be achieved by balancing governance and safety guardrails against enabling makers with the tools. This article is an introduction to both beginning to administer the platform, while also exploring a few points of consideration around scaled operations when adopting the low-code tools.
In future articles, I will dive deeper into some of these topics, highlighting how to implement them with scenario examples.
