1.2 Designing Authentication, Authorization, and Security Architecture

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:

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.

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.