Power Platform Security Roles
Power Platform solutions handle real business data — customer records, financial figures, employee details, confidential contracts. Protecting that data requires a deliberate security strategy. This topic covers the full security model: how security roles control who can do what in Dataverse, how Data Loss Prevention policies stop sensitive data from leaking through connectors, how field-level security protects individual columns, and how to design a security model that balances access with protection.
The Power Platform Security Layers
SECURITY LAYERS (outermost to innermost) Layer 1: Microsoft Entra ID (Azure AD) Authentication Who can log in to Power Platform at all? Controlled by: Microsoft 365 user accounts and licenses Layer 2: Environment Security Who can access this specific environment? Controlled by: Environment roles (Environment Admin, Maker, User) Layer 3: App and Resource Sharing Who can open this specific app or run this specific flow? Controlled by: App sharing, flow sharing settings Layer 4: Dataverse Security Roles What can a user do inside the Dataverse database? Controlled by: Security roles assigned to users or teams Layer 5: Record Ownership Which specific records can a user see and edit? Controlled by: Record owner, team membership, role access level Layer 6: Field-Level Security Which specific columns can a user read or write? Controlled by: Field Security Profiles
Environment Roles: Who Can Access the Environment
Every environment has two built-in environment roles. Environment Administrator has full control — create and delete environments, manage environment settings, manage all resources and users. Environment Maker can create apps, flows, connections, and solutions within the environment but cannot manage environment settings or other users. Assign environment roles in the Power Platform Admin Center → Environments → select environment → Settings → Users + Permissions → Environment roles.
Dataverse Security Roles: The Core Permission System
Security roles define what operations a user can perform on each Dataverse table. Every action — creating a record, reading a record, updating a record, deleting it, appending data, assigning to another user, sharing with another user — has a separate permission level for each table.
The Four Permission Depths
ACCESS SCOPE LEVELS (for each operation on each table)
None ●○○○ User cannot perform this action at all
User ●●○○ User can perform this action only on records they own
(their name is in the Owner field)
Use for: front-line users who manage their own workload
Business Unit ●●●○ User can act on records owned by anyone in
their Business Unit (department)
Use for: managers who oversee a team's records
Organization ●●●● User can act on all records in the organization
(global access)
Use for: administrators, reporting roles, senior staff
EXAMPLE: Service Agent security role
Service Requests table:
Create: User level (can create their own requests)
Read: Business Unit (can see all requests in their dept)
Write: Business Unit (can update dept requests)
Delete: None (cannot delete any requests)
Assign: User (can reassign their own requests)
Built-In Security Roles
Dataverse provides standard security roles that you can use as starting points. System Administrator has full access to everything — use sparingly. System Customizer can modify the data model (add tables, columns) but has limited data access — for developers. Basic User can create and read their own records — minimal access for most end users. Delegate allows a user to act on another user's behalf — rarely needed.
Creating Custom Security Roles
Go to make.powerapps.com → Tables → Security roles (or Admin Center → Environments → select environment → Settings → Security Roles). Click New. Name the role (e.g., "IT Support Agent"). For each table the role needs access to, set the appropriate depth for each operation. A visual filled circle indicates the selected depth — empty circle means no access, quarter-filled means User, half-filled means Business Unit, three-quarter filled means Parent Business Unit, full circle means Organization. Save the role.
Assigning Security Roles to Users
In the Admin Center, open an environment → Settings → Users → select a user. Click Manage security roles. Tick the roles to assign. A user can have multiple roles simultaneously — their effective permission is the highest level across all assigned roles for each table. In Teams, you assign security roles to a Dataverse team and all team members inherit those roles automatically.
Business Units: Organizing the Security Hierarchy
Business Units create a hierarchy that maps to your organization's structure — departments, regions, subsidiaries. Every user belongs to exactly one Business Unit. Record ownership at the "Business Unit" level means the user can access records owned by anyone in the same Business Unit — like a manager seeing all cases in their department without seeing cases in other departments.
BUSINESS UNIT HIERARCHY EXAMPLE
Contoso Corporation (Root Business Unit)
├── Sales Division (Business Unit)
│ ├── North Region (Child BU)
│ └── South Region (Child BU)
└── Operations Division (Business Unit)
├── IT Support (Child BU)
└── Facilities (Child BU)
A North Region Sales Agent:
Business Unit level access → sees all records in North Region
Cannot see South Region records
Cannot see IT Support records
A Sales Division Manager:
Parent Business Unit access → sees all records in North AND South Region
(Parent BU access extends down the hierarchy)
Teams in Dataverse: Group-Based Security
Instead of assigning security roles to each user individually, assign them to Dataverse Teams (not Microsoft Teams — though they can be linked). A team has security roles attached, and every member of the team inherits those roles. When an employee moves to a different department, change their team membership instead of reconfiguring all their individual role assignments.
Owner Teams vs. Access Teams
An Owner Team can own records. All team members share access to team-owned records. Use Owner Teams for shared queues — a pool of agents who collectively own the incoming cases. An Access Team is created dynamically per record and grants temporary access — invite specific users to access one specific record. Useful for record-level collaboration without permanent security role changes.
Field-Level Security: Protecting Sensitive Columns
Security roles control access to entire tables. Field-Level Security (FLS) goes further — it restricts access to individual columns within a table. A Salary column in an Employees table is visible only to HR staff. A Social Security Number column is visible only to payroll admins. All other users see the Employees table normally but cannot see those protected columns — the fields appear blank.
Setting Up Field-Level Security
In make.powerapps.com → Tables → select your table → Columns → select the column you want to protect → click Field Security → turn it on. This makes the column a "secured field." Now create a Field Security Profile: go to make.powerapps.com → Advanced Settings → Security → Field Security Profiles → New. Name it (e.g., "HR - Salary View"). Add the column (Salary). Set Read to Allowed, Update to Allowed or Disallowed based on the profile's purpose. Add users or teams to this profile. Users not in any profile with access to the column see it as blank in all apps and views.
Data Loss Prevention Policies
A Data Loss Prevention (DLP) policy controls which connectors can be used together in a single Power App or Power Automate flow. This prevents users from accidentally (or intentionally) connecting sensitive internal data sources to external consumer services — like sending data from a Dataverse table directly to a personal Gmail account or a social media platform.
The Three Connector Groups in DLP
DLP CONNECTOR GROUPS Business (allowed together — safe for business data): ┌──────────────────────────────────────────────────────┐ │ Dataverse, SharePoint, Teams, Outlook, SQL Server, │ │ Azure services, Dynamics 365... │ └──────────────────────────────────────────────────────┘ Non-Business (personal/consumer services): ┌──────────────────────────────────────────────────────┐ │ Gmail, Twitter, Facebook, Dropbox, Instagram, │ │ personal OneDrive, Slack (personal)... │ └──────────────────────────────────────────────────────┘ Blocked (cannot be used at all in this environment): ┌──────────────────────────────────────────────────────┐ │ Any connector you explicitly choose to block │ └──────────────────────────────────────────────────────┘ DLP RULE: A single flow cannot use connectors from BOTH Business and Non-Business groups simultaneously. This prevents: "Read data from Dataverse → Send to Gmail" (Dataverse is Business, Gmail is Non-Business → policy blocks it)
Creating a DLP Policy
In the Power Platform Admin Center, click Policies → Data policies → New policy. Name it (e.g., "Production Data Protection"). Choose the scope: apply to all environments, all environments except selected, or only selected environments. On the Connectors tab, move connectors between Business, Non-Business, and Blocked groups. Apply the policy. Power Platform immediately enforces it — any existing flows that violate the policy are suspended and cannot run until fixed.
DLP Policy Inheritance
DLP policies are additive — if multiple policies apply to an environment, the most restrictive combination applies. A tenant-wide policy applies to all environments. An environment-specific policy adds further restrictions on top. Admins at the environment level can further restrict (but never relax) the tenant policy. This hierarchy ensures that global security standards are always enforced, even if individual environment admins try to be less restrictive.
Conditional Access: Restricting Who Can Sign In From Where
Microsoft Entra Conditional Access policies add another layer before users even reach Power Platform. Use Conditional Access to require multi-factor authentication (MFA) for all Power Platform access, block access from countries you do not operate in, require managed/compliant devices, or restrict access to specific IP address ranges (for example, only from the office network or VPN).
Configure Conditional Access in the Microsoft Entra admin center (entra.microsoft.com) → Protection → Conditional Access → New policy. Set the policy target to the Power Platform application IDs, set the conditions (location, device compliance, sign-in risk level), and configure the grant controls (require MFA, require compliant device).
Audit Logging: Knowing Who Did What
Power Platform logs all significant user actions — who created which record, who deleted what, who changed a security role assignment, who exported data. Audit logs are stored in the Microsoft Purview compliance portal and in Dataverse's built-in audit tables.
DATAVERSE AUDIT LOG (example entries)
Timestamp User Action Table Record
04 Jun 2025 09:12 Priya Sharma Create Service Req. IT-2025-0445
04 Jun 2025 09:45 James Carter Update Service Req. IT-2025-0445
04 Jun 2025 14:22 Ravi Sharma Delete Customer C-0089
04 Jun 2025 16:01 Liu Wei Share App IT Help Desk
Enable auditing: Admin Center → Environments → select env → Settings →
Audit and logs → Entity auditing → Enable
Key Points
- Power Platform has six security layers: Entra ID authentication, environment roles, app/resource sharing, Dataverse security roles, record ownership scope, and field-level security.
- Security roles define operations (create, read, update, delete) per table. The scope (None, User, Business Unit, Organization) controls which records the user can access.
- Business Units organize users into a department hierarchy. Users with Business Unit access see all records in their unit; Parent BU access extends down through child units.
- Field-Level Security restricts individual columns — users without a matching Field Security Profile see those columns as blank in all interfaces.
- DLP policies control which connectors can be combined — preventing sensitive internal data from flowing to personal consumer services. The policy is enforced at the environment level with tenant-wide policies as the baseline.
- Conditional Access (in Entra ID) enforces MFA, device compliance, and location restrictions before users can access Power Platform at all.
- Audit logging records all user actions in Dataverse and the Microsoft Purview compliance center — essential for compliance, investigations, and accountability.