The Power Platform Admin Roles You Can't Find in the UI

By Kaustubh Giri, Sr Solution Engineer. ~11 min read.

A question I get almost every week goes something like this: “I need to give someone admin access to Power Platform, but I don’t want to make them a Power Platform Administrator. Where do I do that in the admin center?” The short answer is that you mostly can’t. Not in the UI, anyway.

Power Platform now has its own role-based access control (RBAC) model with four built-in roles, scoped to the tenant, an environment group, or a single environment. They fill a real gap. But they’re in preview, you assign them with the API, PowerShell, or the CLI, and they don’t replace Entra roles or Dataverse security roles. This is a common point of confusion, so here’s how I explain it.

A quick caveat: Power Platform RBAC is a preview feature as of October 2026. Microsoft says preview features aren’t meant for production use and may have restricted functionality. Role names, scopes, and admin center support are still changing, so check the current Microsoft Learn articles before you build a process around them.

In this post:

1. Three role systems, one admin center
2. The four built-in RBAC roles
3. How they compare to Entra and Dataverse roles
4. Who needs what
5. Assigning roles step by step
6. Service principals: the object ID trap
7. A self-service role manager I built
8. Least-privilege recommendations
9. Common gotchas

1. Three role systems, one admin center

Three separate systems decide what someone can do in Power Platform, and each is managed somewhere different.

• Microsoft Entra roles (Tenant-wide) - Power Platform Administrator, Dynamics 365 Administrator, Global Reader, AI Administrator, AI Reader. You assign them in Entra or the Microsoft 365 admin center. They apply across every environment.
• Power Platform RBAC roles (Tenant, group, or environment) - Reader, Contributor, Owner, RBAC Administrator. They control admin actions at the Power Platform API layer. You assign them through the API, PowerShell, or the CLI.
• Dataverse security roles (Inside one environment) - System Administrator, System Customizer, Environment Maker, and your custom roles. They control access to business data and apps inside a single environment.

In Microsoft’s framing, RBAC covers administrative control at the Power Platform API layer, while Dataverse keeps its own security for the business data inside each environment. Neither replaces the other.

2. The four built-in RBAC roles

There are four built-in roles. You can’t customize them, and Microsoft says each one can be assigned at the tenant, environment group, or environment scope. Assignments made at a broader scope are inherited by everything below it, so a Reader at the tenant level can read across every environment group and environment.

Role (as named in the API)	Status	What it allows
Power Platform reader	Preview	Read-only access to all resources in scope
Power Platform contributor	Preview	Read and manage all resources, but can’t create or change role assignments
Power Platform owner	Preview	All permissions, including role assignments
Power Platform role-based access control administrator	Preview	Read all resources and manage role assignments. It can’t change other resources.

You can assign these roles to three kinds of principals: users, security-enabled Entra groups, and service principals or managed identities. That last one is the reason the model exists right now. Microsoft says the current focus is on broadening service principal and managed identity support across the Power Platform API and SDKs.

Don’t assign the extra roles: If you list role definitions through the API, you’ll see more than four, including some narrow ones for a single capability. Microsoft says these are reserved for future use and aren’t supported for assignment yet. Stick to the four built-in roles.

The RBAC Administrator role is the one I find most useful. It lets someone manage who has access without also being able to change environments or policies. That’s the split most security teams want: the person granting access is not the person using it.

3. How they compare to Entra and Dataverse roles

Here’s how I explain the difference to customers. Entra roles answer “who is a Power Platform admin for the whole tenant.” RBAC roles answer “what admin actions can this person or app take, and where.” Dataverse roles answer “what data and apps can this person use inside this environment.”

	Entra roles	Power Platform RBAC	Dataverse security roles
Examples	Power Platform Administrator, Dynamics 365 Administrator, Global Reader, AI Administrator, AI Reader	Reader, Contributor, Owner, RBAC Administrator	System Administrator, System Customizer, custom roles
Scope	Whole tenant (AI roles only see AI-related resources)	Tenant, environment group, or environment	One environment’s Dataverse database
Where you assign it	Entra admin center or Microsoft 365 admin center	Power Platform API, PowerShell, or pac CLI	PPAC -> Environments -> Settings -> Users + permissions
Grants access to business data	Not by itself	No	Yes
Status	GA	Preview	GA

One more detail on Dataverse. In environments without a Dataverse database, Environment Admin and Environment Maker are the roles that matter. Once a database exists, full admin access in that environment comes from the System Administrator security role instead.

4. Who needs what

Most delegation requests I see fit one of these rows. The key point: some admin center experiences still require a tenant-wide Entra role, and RBAC roles don’t grant access to them.

Person or app	What I’d assign	Notes
Central platform team running the tenant	Entra: Power Platform Administrator	Keep the group small. Avoid Global Admin for day-to-day work.
Auditor or governance analyst who needs Inventory	Entra: Global Reader	Inventory requires an Entra role. Microsoft says the RBAC roles aren’t supported for Inventory access.
Copilot or AI governance lead who only needs agents	Entra: AI Reader (or AI Administrator to make changes)	Sees agents, agentic apps, agent flows, environments, and environment groups. Doesn’t see canvas apps, model-driven apps, or cloud flows.
Business-unit admin for a set of environments	RBAC: Contributor at the environment group scope	Admin center support for scopes narrower than the tenant is still on the roadmap. Test before you promise it.
Reporting or costing app (service principal)	RBAC: Reader at the narrowest scope that works	Assign it to the enterprise application’s object ID. See section 6.
Deployment pipeline or automation (service principal)	RBAC: Contributor at environment or group scope	Add a Dataverse application user with a security role if it also touches data.
Person who grants access but shouldn’t change anything else	RBAC: RBAC Administrator	Separates granting access from using it.
Consultant or partner assessing one environment	Guest account + environment security group + one Dataverse security role	No tenant admin role at all. See the field note below.

Usage and Monitor have their own prerequisites. Monitor needs tenant-level analytics turned on, and some details depend on your role in the environment. In my experience, people who need tenant-wide visibility in these pages end up needing an Entra role too. Check the current docs for each page before you decide.

From the field: A software company asked me for access to their tenant so I could assess their Copilot Studio and Power Platform setup. Their first instinct was to make me an admin. Here’s what I recommended instead. Invite me as an external guest in Entra so I sign in with my own corporate account and they never manage a password. Add me to the environment’s security group if the environment uses one. Assign only the licenses I actually need. Then, in the admin center, give me only the Dataverse security role required for the assessment in that one environment. No tenant-wide role was needed, and access is easy to remove when the work is done.

5. Assigning roles step by step

There’s no assignment screen for these roles today, so you have three options. All three call the same Power Platform Authorization API, and all of them are in preview.

• PowerShell - New-PPRBACRoleAssignment, Get-PPRBACRoleAssignment, and Remove-PPRBACRoleAssignment in the Microsoft.PowerPlatform.EnterprisePolicies module.
• CLI - pac authorization list-role-definitions, create-role-assignment, and environment and environment group variants.
• REST - /authorization/roleDefinitions and /authorization/roleAssignments, plus environment and environment group endpoints.

Whichever you use, the person running it needs the Entra Power Platform Administrator role or the RBAC Administrator role. Here’s the outline I follow.

1. Step 1: Get the IDs - Tenant ID; principal object ID (user, group, or enterprise application); environment or environment group ID, if you’re scoping narrower than the tenant.
2. Step 2: Assign - Confirm the role names with a list call; create the assignment at the narrowest scope that works; use the right principal type (User, Group, or ApplicationUser).
3. Step 3: Verify - List assignments and filter on the principal; test the actual task the person or app needs to do; record who, what, where, and why.

PowerShell

This is the simplest option. The module accepts the role by name and handles authentication. It can reuse a client ID from an earlier call or from New-PPAuthorizationApplication. Replace the placeholders with your own values.

# Tenant scope: give a user read-only admin access
New-PPRBACRoleAssignment -PrincipalObjectId "<user-object-id>" `
  -PrincipalType User -Role "Power Platform Reader" -TenantId "<tenant-id>"

# Environment group scope: let a service principal manage one group
New-PPRBACRoleAssignment -PrincipalObjectId "<enterprise-app-object-id>" `
  -PrincipalType ApplicationUser -Role "Power Platform Contributor" `
  -TenantId "<tenant-id>" -EnvironmentGroupId "<environment-group-id>"

# Environment scope: a security group as Reader on one environment
New-PPRBACRoleAssignment -PrincipalObjectId "<group-object-id>" `
  -PrincipalType Group -Role "Power Platform Reader" `
  -TenantId "<tenant-id>" -EnvironmentId "<environment-id>"

REST API

If you’re building automation, call the API directly. Get a token for https://api.powerplatform.com/ (for example with Connect-AzAccount and Get-AzAccessToken), then send a POST with the role definition ID, principal, principal type, and scope.

# 1. Confirm role definition IDs
GET https://api.powerplatform.com/authorization/roleDefinitions?api-version=2024-10-01

# 2. Create a tenant-scoped assignment
POST https://api.powerplatform.com/authorization/roleAssignments?api-version=2024-10-01
{
  "roleDefinitionId": "<role-definition-id-from-step-1>",
  "principalObjectId": "<object-id>",
  "principalType": "ApplicationUser",
  "scope": "/tenants/<tenant-id>"
}

# 3. Verify
GET https://api.powerplatform.com/authorization/roleAssignments?api-version=2024-10-01

For narrower scopes there are separate endpoints, such as /authorization/environmentGroups/{id}/roleAssignments. Never put a client secret in a script you share. If the automation runs unattended, use a certificate or a managed identity where you can.

6. Service principals: the object ID trap

This one catches almost everyone. A single app in Entra has three different GUIDs:

• Application (client) ID: what the app uses to sign in. It’s the one people copy by default.
• App registration object ID: the object ID of the app registration itself.
• Enterprise application object ID: the object ID of the service principal in your tenant. This is the one RBAC needs.

Microsoft’s tutorial says to use the enterprise application object ID, which you’ll find under Microsoft Entra ID -> Enterprise applications. If you use the client ID instead, the assignment either fails or points at the wrong object, and the app keeps getting 403s with no obvious reason.

Also note that the Power Platform API only supports delegated permissions right now. For a service principal, you don’t add application permissions to the app registration. You assign it an RBAC role, and that role determines what it can do.

From the field: A software customer wanted to build a Copilot Studio costing dashboard, and their admins couldn’t find where to assign the Reader role. I explained that these roles aren’t in the UI. You assign them through the API or PowerShell, and then the person or app works within those permissions. Once the Reader role was assigned to the app’s enterprise application object ID, it could get tenant- and environment-level Copilot Credit totals and the environment and agent inventory without full admin rights. I’d temper expectations on one thing, though. When we tested the per-agent cost breakdown endpoints from outside the admin center, they returned 403 Forbidden for a user with Reader, for a service principal with Reader, and for Global Admin. At this point it looks like those endpoints only work from the admin center’s own session, not through a role you can grant.

7. A self-service role manager I built

After writing the same PowerShell for several customers, I built a small web page that puts a simple UI on these roles: https://kozziag.github.io/power-platform-role-manager/. It’s not a Microsoft product, just a helper I share with customers.

Power Platform Role Manager

Community tool, open source · Static web page, runs in your browser

What it does:

1. Search for a person, or look up an application, in your own Entra directory
2. See which RBAC roles they already have
3. Assign or remove Reader, Contributor, Owner, or RBAC Administrator in a couple of clicks
4. Keep a log of the changes you make in the session

Why it’s safe to use:

• You sign in with your own Entra ID account, just like signing in to Teams or Outlook.
• It calls Microsoft’s Power Platform and Graph APIs directly from your browser. There’s no backend server, and your tokens and data don’t go anywhere else.
• It can’t grant more than you already have. Microsoft’s permission system decides whether each assignment succeeds, based on the signed-in user’s own admin rights.

What you need:

1. One-time admin consent. Because the page reads directory data and manages role assignments, an Entra admin who can grant tenant-wide consent has to approve it once.
2. The right role to make changes. After consent, anyone can sign in and browse. Only someone who already holds Power Platform Administrator (or RBAC Administrator) can actually assign or remove roles.

8. Least-privilege recommendations

Here’s how I approach delegation with customers today.

• Ask “what do they need to see or change?” not “which admin role should they have?” The answer is often one Dataverse security role in one environment.
• Use Global Reader or AI Reader for visibility. If someone mainly needs Inventory, a read-only Entra role is far safer than Power Platform Administrator.
• Use RBAC roles for apps and automation. Give service principals Reader or Contributor at the narrowest scope that works, not a broad Entra role.
• Use environment groups for scope. If your environments are already grouped by business unit or stage, scope assignments to the group. More on grouping in my environment strategy and DLP post.
• Separate granting access from using it. Give the RBAC Administrator role to whoever approves access, and keep Owner rare.
• Assign to groups, not individuals, where the principal type allows it, so joiners and leavers are handled in Entra.
• Review assignments on a schedule. List them quarterly and remove anything without a current owner or reason. I cover the wider review cycle in my governance toolbox post.

9. Common gotchas

• Looking for the roles in the admin center. You won’t find an assignment screen. Use PowerShell, pac authorization, or the API.
• Expecting RBAC to open Inventory. It doesn’t. Inventory needs Global Admin, Power Platform Administrator, Dynamics 365 Administrator, Global Reader, or the AI roles.
• Calling the Inventory query API as a service principal. The Query Power Platform resources action currently supports delegated user authentication only. Service principals and managed identities get 403.
• Expecting RBAC to grant data access. A Contributor can manage resources but still needs a Dataverse security role to work with the data in an environment.
• Assuming scoped access works everywhere in the UI. Microsoft says admin center support for scopes below the tenant is on the roadmap but not finished.
• Treating preview as production-ready. Keep a fallback path, and write down every assignment you make so you can rebuild or remove it.

Where I’d start

List everyone who holds Power Platform Administrator or Global Admin today, and write down why each person has it. For most of them, the real need is visibility (Global Reader or AI Reader), access to one environment (a Dataverse security role), or an app that needs API access (an RBAC role on an enterprise application). Move those people and apps to the narrower option, then use the RBAC Administrator role to keep control of who grants what. If you’d rather not script it, the role manager page above gives you a simple UI over the same APIs.

Happy to go deeper on any of this.

K.G.

Sources

• Microsoft Learn: Role-based access control for Power Platform admin center (preview)
• Microsoft Learn: Tutorial: Assign roles to service principals (preview)
• Microsoft Learn: Programmability and Extensibility - Authentication
• Microsoft Learn: New-PPRBACRoleAssignment; Microsoft.PowerPlatform.EnterprisePolicies module
• Microsoft Learn: Microsoft Power Platform CLI authorization command group
• Microsoft Learn: Power Platform API - Role Based Access Control (Create Environment Group Role Assignment)
• Microsoft Learn: Power Platform inventory
• Microsoft Learn: Monitor the health of your resources
• Microsoft Learn: Role-based security roles for Dataverse; Assign security roles

---

Statuses reflect publicly available information as of October 2026. Preview features may change. Customer examples are anonymized.

Get new posts by email

Email addressSubscribe

Provider: your email provider