Introduction

Permissions and security models are the backbone of any enterprise-grade application. In the Microsoft Power Platform—covering Power Apps, Power Automate, Dataverse, and Connectors—understanding how permissions flow is critical to designing secure, compliant, and scalable solutions.

Among the most important concepts are:

This article explains both, compares them, and shows how Power Platform uses these models in real scenarios.

What Are Delegated Permissions?

Delegated permission means the system runs under the identity and privileges of the logged-in user.

In simple words:

Where Delegated Permission is Used in Power Platform

1. Power Apps Canvas Apps

This means:

Canvas apps do NOT support elevated permission.

2. Power Automate flows using "User Connection"

If a flow uses a connector authenticated with a user's connection:

Example:
If a flow using your SharePoint connection tries to update a list item, you don't have Edit permission for then the flow fails.

3. Approvals

Approval actions (Create Approval, Start and Wait for an Approval):

You cannot approve/reject items or write data where that connection has no access.

What Are Elevated Permissions?

Elevated permission means the system executes using a privileged account or an application identity, not the logged-in user.

This allows:

This is typically achieved through:

Where Elevated Permission Is Used in Power Platform

1. Dataverse Plug-ins (Server-Side Logic)

Plug-ins can run as:

Running as SYSTEM allows:

2. Power Automate Flows Using Service Accounts

If a flow's connection uses a service account, the flow executes with that account's full privileges.

Example:

3. Custom Connectors with Application Permissions

Connecting to:

This is the most powerful form of elevated permission.

4. Azure Functions or APIs Called from Power Apps

Architecture:

Power Apps - Custom Connector - Azure Function - Dataverse/SharePoint/API

The Azure Function runs using managed identity or app registration, enabling:

Why Delegated vs Elevated Matters

AspectDelegatedElevated
Runs asLogged-in userPrivileged account / app
Bypass user permissionsNoYes
Secure for end usersYesNeeds control
Used in Canvas AppsYesNo
Used in Model-Driven(forms)(plug-ins)
Used in Power AutomateYes (user connection)Yes (service account)
Appropriate for sensitive tasksNoYes
Performs admin tasksNoYes

How Power Platform Decides Which Permission to Use

In Power Apps

In Power Automate

In Approvals

In Connectors

Real-World Scenarios

Scenario 1: User submits form - flow updates restricted SharePoint list

If the user has no Edit access:

Scenario 2: Need to update all Dataverse records nightly

Use:

Scenario 3: Need to run logic with SYSTEM privilege

Use:

Scenario 4: Power Apps needs to perform admin-level operation

Solution:

Best Practices

Use delegated permission for:

Use elevated permission for:

Always log/monitor elevated operations:

Never give normal users access to service account credentials.

Conclusion

Delegated and elevated permissions are fundamental to building secure, scalable solutions in the Power Platform.

A well-architected solution usually combines both: