Skip to content

License to role mapping risks

Opt-out of automatic license-based user roles management

Opt-out of automatic license-based user roles management - Power Platform | Microsoft Learn

Automatic role assignment

Assign security roles - Power Platform | Microsoft Learn

1. The basics: licensing vs roles

ConceptDescriptionWho controls it
LicensingDetermines what features a user is entitled to use.Microsoft 365 / Azure AD license assignment
Security rolesDetermine what data and actions a user can access or perform.Environment admin or Dataverse admin

The problem is that Power Platform can automatically assign certain roles when a license is granted, or users can gain broad privileges indirectly through environment defaults.

2. How license-to-role mapping works

Licenses unlock capabilities, and Power Platform can automatically assign the minimum roles or permissions needed to use them.

LicenseWhat it unlocksAutomatic or implied role assignments
Microsoft 365 (E3/E5)Basic Power Apps and Power Automate features (using M365 data sources like SharePoint, OneDrive)Users can use Power Apps shared with them but cannot access Dataverse by default.
Power Apps / Power Automate per-user planPremium connectors + Dataverse accessWhen they open an environment, they get the Basic User role in Dataverse automatically.
Dynamics 365 (Sales, Service, etc.)Apps built on DataverseAssigns specific Dataverse app roles (like Salesperson, Customer Service Rep) automatically.
Power Apps Developer PlanPersonal developer environment with DataverseUser automatically becomes System Administrator in their own developer environment.

3. Why this can be a security risk

A. "Silent" Dataverse access

When a user has a Power Apps license and is added to an environment (for example, by sharing an app), Power Platform may automatically assign them a "Basic User" role in Dataverse for that environment.

Impact:

  • They now have Dataverse access — not just app access.
  • If the environment has tables with permissive roles (like organization-level read), that user can see all records beyond the app’s scope.

B. Developer environments with Dataverse admin rights

Every user with a Power Apps Developer Plan can create a personal environment with full Dataverse admin rights.

Impact:

  • They become System Administrator in that environment.
  • They can connect to company data sources (via connectors).
  • They can export data or build flows that move data outside the organization.

C. Shared licenses grant broad roles

Dynamics 365 and Power Platform app sharing can auto-assign application-level roles.

Impact:

  • Users might gain access to tables and data beyond what they need.

4. Real-world example of risk

Scenario: A developer shares a Dataverse-backed app with "Everyone in the organization", and a Dataverse table has organization-level read permissions. Suddenly, every employee can query/export all data in that table (for example via Power BI or Dataverse APIs).

5. How to prevent or mitigate these risks

  • Control environment creation (restrict to admins; disable personal developer environments unless needed).
  • Restrict automatic role assignment; use custom security roles; avoid organization-level scope for sensitive tables.
  • Manage sharing: avoid "Everyone in organization"; use Azure AD groups.
  • Audit and monitor user-role assignments and Dataverse access.
  • Separate Dev/Test/Prod environments and apply strict role assignments in production.