1.2 Designing Authentication, Authorization, and Security Architecture

Microsoft Power Platform Developer Associate PL-400

Track your progress as you read

Finished sections get a check mark.

1 Introduction, Exam Overview & Developer Toolchain

0.1 PL-400 Exam Facts 0.2 Audience Profile & Required Developer Skills 0.3 The Power Platform Developer Toolchain 0.4 Extension-Point Map & AI in the Developer Workflow

2 Create a Technical Design

1.1 Analyzing Technical Architecture and Choosing Out-of-the-Box vs. Custom Solutions 1.2 Designing Authentication, Authorization, and Security Architecture 1.3 Deciding Where Business Logic Runs and Choosing the Right Table Type 1.4 Designing Reusable Power Apps Components and Custom Connectors 1.5 Designing Dataverse Code Components, Automations, and Integrations

3 Build Power Platform Solutions

2.1 Managing Power Platform Environments for Development 2.2 Dataverse Security Roles for Code Components, Least Privilege & Troubleshooting Operational Security 2.3 Solutions, Managing Dependencies & Solution Layers 2.4 Environment Variables & Connection References 2.5 Power Platform Pipelines & CI/CD with Power Platform Build Tools

4 Implement Power Apps Improvements

3.1 Complex Power Fx Formulas and Functions 3.2 Building Reusable Canvas Component Libraries 3.3 Invoking Power Automate Cloud Flows from a Canvas App 3.4 Troubleshooting Canvas and Model-Driven Apps with Monitor and Browser Debugging Tools 3.5 Optimizing Canvas and Model-Driven App Performance

5 Extend the User Experience

4.1 The Client API Object Model & JavaScript Form Scripting 4.2 Event Handler Registration & Navigation to Custom Pages via the Client API 4.3 Client Scripting Against the Dataverse Web API; Command Bar & Buttons with Power Fx and JavaScript 4.4 PCF Fundamentals: The Component Manifest & Lifecycle Events 4.5 Implementing PCF Component Interfaces; Device, Utility & Web API Features 4.6 Packaging, Deploying & Consuming a PCF Component

6 Extend the Platform: Dataverse Plug-ins & Custom APIs

5.1 Plug-in Fundamentals & the Event Execution Pipeline Stages 5.2 Execution Context & Implementing Business Logic in Plug-ins 5.3 Pre/Post Images & Organization Service Operations in Plug-ins 5.4 Registering Plug-ins with the Plug-in Registration Tool & Optimizing Plug-in Performance 5.5 Custom API Messages & Plug-ins That Implement a Custom API 5.6 Configuring Dataverse Business Events

7 Extend the Platform: Custom Connectors

6.1 Open API Definitions: Building and Extending a Custom Connector 6.2 Authentication and Policy Templates for Custom Connectors 6.3 Importing Definitions and Creating Connectors for Azure Services 6.4 Azure Functions in Custom Connectors and Data Transformation

8 Extend the Platform: Platform APIs & Azure Functions

7.1 Dataverse Web API Operations & OAuth Authentication 7.2 Organization Service Operations, Concurrency, Transactions & Bulk Operations 7.3 Service Protection API Limits & Retry Policies 7.4 Azure Functions for Long-Running, Scheduled & Event-Driven Workloads 7.5 Authenticating to Power Platform with Managed Identities

9 Extend the Platform: Power Automate Cloud Flows

8.1 Dataverse connector triggers/actions, trigger filters & retry policies 8.2 Complex expressions & flow control with error handling 8.3 Sensitive input/output parameters & Azure Key Vault 8.4 Reusable child flows & Microsoft Entra ID service principals

10 Develop Integrations

9.1 Publishing Dataverse Events: IServiceEndpointNotificationService & the Plug-in Registration Tool 9.2 Registering Service Endpoints: Webhooks, Azure Service Bus & Event Hub 9.3 Data Synchronization with Change Tracking & Alternate Keys 9.4 Upsert-Based Synchronization with the UpsertRequest Message

11 Exam Readiness & Practice

10.1 Cross-Domain "Where Do I Implement This?" Decision Framework 10.2 Exam-Day Strategy, PL-400 Item Styles & Study Plan

1.2 Designing Authentication, Authorization, and Security Architecture

Key Takeaways Explain This Topic AI

Authentication (who is calling) and authorization (what they can do) are separate design layers governed by Entra ID and Dataverse's security model respectively.

Unattended integrations use the client credentials flow or a managed identity; interactive users use the authorization code flow with delegated permissions.

Security roles grant access via privileges scoped to access levels from None up to Organization (Global), and Dataverse applies the most permissive level across all assigned roles.

Business units, teams (owner, Entra ID group, and access teams), row sharing, and field security profiles together control record- and field-level access.

DLP policies can block a planned connector's data group outright, so security architecture must be evaluated during design, not after deployment.

Last updated: July 2026

Security design on PL-400 splits into two distinct questions: authentication (proving who or what is calling) and authorization (deciding what that identity is allowed to see or do). A solution architect must design both layers, and must also account for platform-level security features like data loss prevention that constrain what connectors and components are even available.

Authentication Strategy with Microsoft Entra ID

Every Power Platform environment is backed by Microsoft Entra ID (formerly Azure AD). Interactive users authenticate through Entra ID sign-in, but system-to-system integrations need a different pattern:

App registrations represent an application's identity in Entra ID and hold the client ID, secret or certificate, and API permissions it needs.

Delegated permissions act on behalf of a signed-in user (used with the authorization code flow ) and are scoped by whatever that user is already allowed to do.

Application permissions act as the app itself, with no signed-in user, used with the client credentials flow — the standard pattern for a background service, Azure Function, or middleware integration calling the Dataverse Web API.

Managed identities let an Azure resource (Function, Logic App) authenticate to Power Platform without storing a secret at all, and are the preferred pattern whenever the calling service already runs in Azure.

Choosing between these is a design decision: if a human is present and consent can be granted interactively, delegated/authorization-code is appropriate; if the caller is unattended, client credentials or a managed identity is required.

Dataverse's Authorization Model

Once a caller is authenticated, Dataverse's authorization model decides what data and actions they can reach.

Business Units

A business unit (BU) is a hierarchical container for users, teams, and security roles. Every environment has one root BU, and child BUs can model organizational structure (regions, departments). Security roles are frequently scoped relative to a user's BU.

Security Roles

A security role is a named collection of privileges (Create, Read, Write, Delete, Append, Append To, Assign, Share, plus miscellaneous privileges) applied per table. Each privilege carries an access level :

Access level Scope
None No access
User (Basic) Only records the user owns
Business Unit (Local) Records owned by users in the caller's own BU
Parent: Child Business Unit (Deep) Records owned by the caller's BU and its child BUs
Organization (Global) All records regardless of BU

Users can hold multiple roles; Dataverse grants the most permissive access level across all assigned roles for each privilege.

Teams

Three team types support different sharing patterns: owner teams can own records directly and have security roles assigned to them; Microsoft Entra ID group teams sync membership automatically from a security or Microsoft 365 group; access teams (built from access team templates) share records without owning them or holding roles, useful for lightweight ad hoc collaboration.

Row and Field-Level Security

Beyond roles, individual records can be shared to specific users or teams ( record sharing ), and hierarchical security can grant managers visibility into direct reports' records. For sensitive columns (SSNs, salary), field security profiles restrict Read/Create/Update at the column level independent of the table-level security role.

Assessing the Impact of Platform Security Features

Data loss prevention (DLP) policies classify every connector into a group — commonly Business, Non-Business, or Blocked — at the tenant or environment level, and prevent flows or apps from mixing connectors across groups. A custom connector you design in Domain 1 may be unusable in production if a DLP policy blocks its data group, so DLP must be evaluated during design, not after deployment.

Security feature Design impact
Business units Determines how BU-scoped access levels behave; restructuring BUs later is disruptive
Security roles Must grant least privilege while still letting code components (plug-ins, flows) function
Teams Owner teams needed wherever shared record ownership is required
Row sharing Adds per-record overhead; prefer role/BU design over manual sharing at scale
DLP policies Can block a planned connector or custom connector outright

A technical design that ignores these features until deployment routinely fails integration testing when a service account lacks a privilege, or a custom connector lands in a blocked DLP group.

Consent and Least Privilege in Practice

App registrations used for application-permission (client credentials) flows require an admin to grant consent for the specific Dataverse scopes requested — this is a deliberate control point, and a technical design should list exactly which scopes an integration needs rather than requesting broad access by default. The same principle of least privilege applies to the application user created in Dataverse for that app registration: it should be assigned only the security role privileges the integration actually exercises, at the narrowest access level that still satisfies the requirement, rather than a broad Organization-level role granted "to be safe." Over-privileged service accounts are a recurring audit finding, and the exam frequently tests whether a candidate recognizes when a design grants more access than the stated requirement needs.