Understanding Delegated and Elevated Permission in the Power Platform

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:

• Delegated Permission

• Elevated Permission (also known as Application Permission or Privileged Execution)

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:

• Whatever the user is allowed to do, the app/flow will also be allowed to do.

• If the user doesn't have permission, the app/flow cannot override it.

Where Delegated Permission is Used in Power Platform

1. Power Apps Canvas Apps

• SharePoint connector - runs as the logged-in user.

• Dataverse connector - runs using the user's Dataverse security roles.

• SQL connector (standard mode) - runs with the user's SQL credentials (if using Azure AD)

This means:

• If the user has read a list, the app can read.

• If the user has No delete permission, app cannot delete.

• If the user is blocked, app operations will fail.

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:

• It always executes as that user.

• It cannot bypass permission boundaries.

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):

• Run under the identity of the owner of the connection

• They follow delegated permission

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:

• Accessing resources where the user has no permission

• Performing admin-level operations

• Running secure backend logic independent of the user

This is typically achieved through:

• Service accounts

• Azure AD app registrations (Client ID + Secret/Certificate)

• Custom connectors with OAuth 2.0 client credential flow

• Dataverse Plug-ins running as "System"

• Power Automate with Service Account connection

• Azure Functions/APIs performing privileged tasks

Where Elevated Permission Is Used in Power Platform

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

Plug-ins can run as:

• Calling User (delegated), OR

• System user (elevated)

Running as SYSTEM allows:

• Changing restricted fields

• Updating records the user cannot access

• Bypassing business rules and restrictions

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:

• A user submits a request in Power Apps

• Flow updates a SharePoint list where the user has only "Read"

• Flow uses "service account connection", so update succeeds

3. Custom Connectors with Application Permissions

Connecting to:

• MS Graph with Application Permission

• SharePoint App-Only access (ACS or MSAL)

• Azure AD App with Client Credentials

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:

• Elevated CRUD operations

• Restricted admin tasks

• Secure data access

Why Delegated vs Elevated Matters

Aspect	Delegated	Elevated
Runs as	Logged-in user	Privileged account / app
Bypass user permissions	No	Yes
Secure for end users	Yes	Needs control
Used in Canvas Apps	Yes	No
Used in Model-Driven	(forms)	(plug-ins)
Used in Power Automate	Yes (user connection)	Yes (service account)
Appropriate for sensitive tasks	No	Yes
Performs admin tasks	No	Yes

How Power Platform Decides Which Permission to Use

In Power Apps

• Canvas Apps - Always delegated

• Model-driven - Mixture (delegated UI + elevated server logic)

In Power Automate

• Depends on the connection used.

• If connection is personal account - delegated.

• If connection is service account - elevated.

In Approvals

• Always follow the permission of the connection owner.

In Connectors

• Standard connectors use delegated permission.

• Premium connectors + custom connectors can use elevated (client credentials).

Real-World Scenarios

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

If the user has no Edit access:

• Canvas app fails (delegated)

• Flow succeeds (if using service account connection)

Scenario 2: Need to update all Dataverse records nightly

Use:

• Scheduled flow

• Service account connection - elevated permission

Scenario 3: Need to run logic with SYSTEM privilege

Use:

• Dataverse plug-in running as SYSTEM

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

Solution:

• Power Apps - Custom Connector - Azure Function (managed identity) - Elevated action

Best Practices

Use delegated permission for:

• User-facing apps

• Normal CRUD operations

• Simple approvals

• Low-risk actions

Use elevated permission for:

• Back-office logic

• Nightly jobs

• Exemption workflows

• Business-critical updates

• Security-related tasks

Always log/monitor elevated operations:

• Use Application Insights

• Add audit logs in Dataverse

• Restrict who can change service-account connections

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.

• Delegated permission ensures apps and flows respect the user's own access rights.

• Elevated permission enables backend logic to run with higher privileges through service accounts, Dataverse plug-ins, Azure AD apps, and custom connectors.

A well-architected solution usually combines both:

• Front-end (delegated): secure, user-based actions

• Back-end (elevated): robust automation with privileged access