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
Join the conversation! Your thoughts help the community grow.