Governance & Security
From the field archive · Learned in 2023
Segregation of Duties and Audit Logs in Power Automate
A manufacturer asked me how to stop one group from building automations and still prove who changed what. Here's how I answered in 2023, and what I'd do today.
In early 2023, a request reached me marked high importance. A manufacturer's compliance team wanted to stop a specific group of users from creating or editing automations. They also wanted a record of what changed whenever someone did edit an app or a flow. Their ERP system handled this with role-based user profiles, so they expected Power Platform to have the same switch.
This is a common point of confusion. Power Platform doesn't have a single "segregation of duties" setting. You get segregation of duties by combining several controls: who can build in which environment, what they can do with data, how changes reach production, and an audit trail that shows what happened. In this post I go through how I answered that question in 2023 and how I'd answer it today.
Power Automate activity now has its own Microsoft Purview article and event list. It covers flow creation, edits, deletion, and permission changes. Run-level detail is still not in Purview. For that, Microsoft points you to Application Insights, cloud flow run records in Dataverse, or Power Automate analytics in the admin center. Managed Environments now let you limit how broadly makers can share apps, flows, and agents. Admin delegation has a new layer too: Power Platform RBAC roles, still in preview. Dataverse security roles work the way they always have, and the distinction between System Administrator and System Customizer still matters.
01The question behind the question
When someone asks for segregation of duties, I first ask which duties they want separated. In my experience, auditors usually care about four things: who builds, who approves, who deploys to production, and who can review the evidence afterward. Each one maps to a different Power Platform control.
| Duty | Typical owner | Power Platform control |
|---|---|---|
| Build | Makers, in development environments | Environment Maker role, Dataverse security roles, environment access |
| Approve | Business owner or platform team | Solution review and a pipeline approval step |
| Deploy | Platform team or a service identity | Solutions and pipelines into production environments where makers have no build rights |
| Review evidence | Compliance or audit | Microsoft Purview Audit, Dataverse auditing |
The takeaway: if you only lock down "who can build", you've covered one of the four duties.
02Layer 1: who can build where
In environments without a Dataverse database, two environment roles matter. Environment Admin can run all administrative actions on the environment. Environment Maker can create apps, connections, custom APIs, and flows, but the role doesn't grant access to data in the environment. Once an environment has a Dataverse database, full admin rights come from the System Administrator security role instead.
The default environment is where expectations usually break. Microsoft's guidance says that whenever a new user signs up for Power Apps or Power Automate, they're automatically added to the Maker role of the default environment. That's by design. The default environment is meant for personal productivity, so I don't try to turn it into a locked-down production space.
Here's how I approach it instead:
- Keep the default environment for personal productivity, and say so clearly to makers.
- Put regulated or business-critical processes in dedicated environments where you decide who holds the maker and customizer roles.
- Restrict who can access those environments with a security group, and keep the maker list short.
- Turn on Managed Environments and use sharing limits so a flow or app can't quietly spread to the whole organization.
For that manufacturer, what they actually needed was a production environment where the business users could run solutions but not change them. The group they wanted to restrict could keep building in the default environment for personal work. The processes the auditors cared about lived in an environment where only the platform team had build rights. Once we framed it that way, the "restrict this group" request mostly went away.
For a fuller walkthrough of environment strategy and data policies, see Environment Strategy and DLP: What I Recommend.
03Layer 2: Dataverse security roles
Back in 2020, as a field engineer on Dynamics CRM, I got a version of this question that still comes up: "What's the real difference between System Administrator and System Customizer?" It matters for segregation of duties, because one of them can read everything and the other can't.
| Role | What Microsoft documents | How I use it |
|---|---|---|
| System Administrator | Full permission to customize the system and manage the environment. Can view all data. | A small platform team, ideally with just-in-time elevation |
| System Customizer | Permission to customize the system. Can view all custom tables, but only the account, contact, and activity rows they created. | Developers who build but shouldn't browse business data |
| Environment Maker | Creates apps, connections, custom APIs, and flows. No data privileges by itself. | Citizen makers, paired with a data role only where needed |
Two details from the documentation are worth knowing. First, security roles are additive, and privileges come from the least restrictive role a user holds. You can add System Customizer to someone temporarily and remove it later without touching their other roles. Second, Microsoft notes that a copied System Customizer role might not provide the same access as the original.
In late 2024 a customer asked me to help design a custom security role for their Power Platform builders. Their plan was to copy System Customizer and trim it down. I suggested starting from a minimal role and adding privileges as testing showed they were needed, rather than subtracting from a broad one. We then tested every app and flow with an account that had no customization privileges. Microsoft recommends that kind of testing too, and it catches problems before users do.
04Layer 3: the audit trail in Purview
The second half of the manufacturer's request was "show us what changed." In 2023 I pointed their team to the Power Apps and Power Automate activity logging articles on Microsoft Learn. That was enough to show auditors that changes to apps and flows were being captured. Today the Power Automate guidance is clearer about both what's covered and what isn't.
Getting access
- Turn on auditing for the Power Platform production environments you want to monitor.
- Assign the reviewer the Audit Logs or View-Only Audit Logs role in Microsoft Purview.
- In the Purview portal, open Solutions → Audit, then filter the Activities list for Power Automate events.
- For automated export, developers can read the same logs through the Office 365 Management API.
What you'll see
| Category | Events |
|---|---|
| Flows | Created flow, edited flow, deleted flow |
| Flow permissions | Edited permissions (for example, adding a co-owner), deleted permissions |
| Trials | Started or renewed a paid trial |
| Hosted RPA | A hosted RPA bot joined to the tenant's Microsoft Entra ID |
Each record carries useful fields for an auditor. They include the user, whether the action was taken by a user or an admin, the connector names in the flow definition at the time of the event, and the permission type when a flow is shared (owner or run-only).
Purview captures lifecycle and permission events, not individual runs, action executions, or connector calls at runtime. Only cloud flow activity appears in Purview. Desktop flow activity is in Dataverse audit logs. Purview also tells you that a flow was edited, not exactly what changed inside it. If auditors need the actual change, you need solutions in source control so you can compare versions.
I'd temper expectations on one more point. A single user action can produce several logged events, because logging happens at the SDK layer. Build your reports around operations and users, not raw event counts.
05Layer 4: separating build from deploy
Roles and audit logs only get you so far if the same person can build in production. The strongest segregation of duties control I recommend is structural. Makers build in development. Changes move as solutions. Someone else approves the promotion to production.
Makers build
- Maker and customizer roles live here
- Everything goes into a solution
Someone else approves
- Solution and connector review
- Approval recorded in the pipeline
Users run
- No maker rights for business users
- Purview and Dataverse auditing turned on
This is also how you answer the "what changed" question properly. Every production change is a solution version, and you can compare versions.
06Delegating admin work
Segregation of duties applies to administrators too. In 2023, most of the customers I worked with had only two options: make someone a tenant-wide Power Platform Administrator, or give them nothing. That's no longer the only choice. Power Platform RBAC roles (Reader, Contributor, Owner, and RBAC Administrator) can be scoped to the tenant, an environment group, or one environment. The RBAC Administrator role is useful here, because it separates the person who grants access from the person who uses it. These roles are still in preview, and you assign them with the API, PowerShell, or the CLI. I cover them in detail in The Power Platform Admin Roles You Can't Find in the UI.
07Cost and limits, briefly
In 2021 a customer asked me a related question: "Is there any cost or limit to running flows?" It comes up in segregation-of-duties conversations because restricted users often ask to run automations under a shared account instead. My answer then and now: yes, flows are subject to licensing and to request limits. Running everything under one account concentrates both the cost and the audit trail on a single identity. I don't quote numbers from memory, because they change. Check the current Power Platform licensing guide and the request limits and allocations article. For monitoring runs, use Power Automate analytics in the admin center or Application Insights.
Where I'd start
Write down the four duties (build, approve, deploy, review) and who owns each one. Keep the default environment for personal productivity and move audited processes into dedicated environments with a short maker list. Give developers System Customizer instead of System Administrator. Turn on auditing and make sure your compliance team can search Power Automate events in Purview. Then put pipelines in place so nobody builds directly in production.
Happy to go deeper on any of this.
— K.G
Sources
- Microsoft Learn: View Power Automate activity logs in Microsoft Purview (updated April 2026)
- Microsoft Learn: Role-based security roles for Dataverse
- Microsoft Learn: Privileges required for Dataverse customization (updated April 2026)
- Microsoft Learn: Migrating apps and flows from the default environment
- Microsoft Learn: Secure the default environment
- Microsoft Learn: Requests limits and allocations (check current values)
Get new posts by email
Provider: your email provider
