1️⃣ Security in Power Platform — Hierarchical View
Think of security in the Power Platform as layered from broad tenant-wide controls at the top down to record-level access at the bottom.
Level 1 – Tenant-Wide Security
-
Scope: Entire Microsoft 365 tenant (all environments & users)
-
Controlled by: Microsoft 365 Admin / Power Platform Admin
-
Key Aspects:
-
Azure AD Authentication (SSO, MFA, Conditional Access)
-
Licensing & Entitlements (e.g., which users can even access Power Apps/Automate)
-
Tenant-level DLP Policies (block high-risk connectors across all environments)
-
Tenant Isolation Settings (limit data movement between tenants)
-
-
Real-World Use:
Block Twitter connector globally to ensure no data leaves the tenant.
Level 2 – Environment Security
-
Scope: One specific Power Platform environment
-
Controlled by: Power Platform Environment Admin
-
Key Aspects:
-
Environment Roles:
-
Environment Admin – full control over apps, flows, settings
-
Environment Maker – can create resources but not manage security
-
-
Environment DLP Policies – can override global policies for specific needs
-
Security Groups for environment access control
-
-
Real-World Use:
Only HR staff have access to HR App Environment; marketing cannot even see it in their app list.
Level 3 – Dataverse Security Roles
-
Scope: Dataverse database within an environment
-
Controlled by: Dataverse System Administrator
-
Key Aspects:
-
Security Roles – define CRUD permissions for tables, forms, dashboards
-
Access Levels:
-
Global (Organization)
-
Business Unit
-
Child Business Unit
-
User-Level
-
None
-
-
Team Access – security roles can be assigned to teams for group-based permissions
-
-
Real-World Use:
Sales reps can only view their own opportunities; sales managers can view team opportunities.
Level 4 – Business Unit Hierarchy
-
Scope: Structural division of data ownership in Dataverse
-
Controlled by: Dataverse Admin
-
Key Aspects:
-
Parent-Child structure
-
Security roles assigned at business unit level cascade down
-
-
Real-World Use:
APAC sales team is a child business unit under Global Sales; their data is visible to global managers but not to EMEA sales reps.
Level 5 – Record-Level Security
-
Scope: Single record in a Dataverse table
-
Controlled by: Sharing & Access Teams
-
Key Aspects:
-
Record Sharing – user-to-user or user-to-team
-
Access Teams – ad-hoc access without changing security roles
-
-
Real-World Use:
Share a sensitive contract record with the legal team only.
Level 6 – Field-Level Security
-
Scope: Individual fields (columns) in a table
-
Controlled by: Field Security Profiles
-
Key Aspects:
-
Can Read/Update/Create at field level
-
Sensitive fields (e.g., salary, personal ID) are masked unless explicitly allowed
-
-
Real-World Use:
HR can see salary field; hiring managers can’t.
2️⃣ Data Loss Prevention (DLP) — Hierarchical Enforcement
| Level | Policy Scope | Description | Example |
|---|---|---|---|
| Tenant-level DLP | All environments | Prevents specific connector combinations globally | Block Twitter & Dropbox in all environments |
| Environment-level DLP | One environment | Overrides or refines tenant policy for local needs | Allow Salesforce in Sales environment only |
| Per-app DLP | Individual app/flow | Controlled indirectly via connector rules | A specific flow can only use internal connectors |
3️⃣ How They Work Together
-
Tenant Admin sets broadest rules → applies everywhere.
-
Environment Admin narrows rules for local needs.
-
Dataverse Security Roles → define what users can do in a database.
-
Business Units & Teams → structure who sees what.
-
Record & Field Security → most granular control.
4️⃣ Best Practices
-
Least privilege → give only what’s needed.
-
Separate environments for Dev / Test / Prod.
-
Use security groups for environment access.
-
Audit & monitor via Power Platform Admin Center & Audit Logs.
-
Review DLP regularly when new connectors are added.