Security by Design: Auth, Roles & DLP
Every Power Platform solution needs a security strategy. Learn how to design authentication flows, configure Dataverse security roles, and assess the impact of DLP policies on your solution components.
Why security architecture comes first
Imagine building a house without planning where the locks go.
You would not build every room, install the furniture, and then figure out which doors need locks. You plan security into the blueprint from day one — who gets a key to the front door, who can access the filing cabinet, and which rooms are restricted.
Power Platform security works the same way. You design authentication (proving who you are), authorization (what you are allowed to do), and data boundaries (which connectors can talk to each other) before writing a single line of code.
Bolt-on security is expensive, fragile, and always has gaps. Baked-in security is invisible to users and enforced at the platform level.
Authentication patterns for Power Platform
Authentication determines who is making the request. Different solution components authenticate differently.
| Component | Authentication Method | Identity Used |
|---|---|---|
| Canvas app | Entra ID (automatic) | Current user’s identity |
| Model-driven app | Entra ID (automatic) | Current user’s identity |
| Cloud flow (interactive) | Connection reference | Connection owner’s identity |
| Cloud flow (automated) | Service principal or app user | Application identity |
| Plug-in | Execution context | Calling user or system |
| Custom connector | OAuth 2.0, API Key, or Basic | Configured per connection |
| PCF component | Inherits from hosting app | Current user’s identity |
| Azure Function (called from PP) | Managed identity or OAuth | Function’s managed identity |
Exam tip: Connection references vs connections
A connection is a specific authenticated link to a service (e.g., “Elena’s SharePoint connection”). A connection reference is a solution-aware pointer that says “use whatever connection is mapped to this reference in this environment.”
Connection references are essential for ALM — they let you deploy a solution to a new environment without hardcoding connections. The exam often tests whether you know to use connection references (not raw connections) in solutions.
Dataverse security model
Dataverse security controls what users can do once authenticated. It operates through four layers that stack on top of each other.
The security stack
- Security roles — Define permissions (Create, Read, Write, Delete, Append, etc.) at the table and column level
- Teams — Group users and assign shared roles (owner teams own records; access teams share specific records)
- Business units — Organisational hierarchy that segments data access (users see data in their BU by default)
- Row sharing — Grant access to individual records beyond what roles and BUs allow
| Feature | Security Roles | Teams | Business Units | Row Sharing |
|---|---|---|---|---|
| Scope | Table and column permissions | Group role assignment | Organisational data segmentation | Individual record access |
| Granularity | User, BU, Parent-child BU, Organisation | Inherited by all team members | Hierarchical (parent sees child) | Specific record to specific user/team |
| Best for | Role-based access (sales, admin, reader) | Sharing permissions across departments | Multi-division orgs with data boundaries | Exceptions — one-off record access |
| Exam focus | Choosing the right access level (User vs BU vs Org) | Owner teams vs access teams | When to create new BUs for developers | Performance impact of excessive sharing |
Security roles for developers
As a PL-400 developer, you need to understand security roles from two angles:
- Designing roles for your solution’s users (what can they access?)
- Configuring roles for your code components (what permissions do plug-ins and flows need?)
Principle of least privilege: Every component should have only the permissions it needs. A plug-in that reads and updates Contact records should not have Organisation-level Delete permission on every table.
Scenario: Elena designs security for a claims system
Elena Vasquez is the platform lead at Meridian Healthcare. She is designing security for a new claims processing app:
- Claims agents can create and edit claims in their own business unit. They cannot see claims from other regions.
- Claims managers can see all claims in their BU and child BUs. They can approve claims.
- Auditors can read all claims across the organisation but cannot edit anything.
- The automated approval flow needs to update claim status regardless of which BU owns the record.
Elena designs:
- Claims Agent role: Create + Read + Write at Business Unit level on Claims table (BU-level lets them see all claims in their region, not just their own)
- Claims Manager role: Read + Write at Business Unit level, Approve privilege at BU level
- Auditor role: Read at Organisation level only
- Application user (for the flow): Read + Write at Organisation level — using a service principal, not a user’s identity
DLP policies and their impact on development
Data Loss Prevention (DLP) policies in Power Platform group connectors into categories. They do not inspect data content — they control which connectors can be used together in a single app or flow.
Connector groups
| Group | What it means | Example |
|---|---|---|
| Business | Connectors trusted for business data | Dataverse, SharePoint, Office 365 |
| Non-business | Connectors that should not mix with business data | Twitter, personal email, public APIs |
| Blocked | Connectors that cannot be used at all | Any connector the admin explicitly blocks |
The rule: A single app or flow can only use connectors from ONE group (business or non-business). If your canvas app uses Dataverse (business) and Twitter (non-business), DLP will block it.
Impact on developers
DLP policies directly affect what you can build:
- Custom connectors may be blocked or restricted by default
- Canvas apps that mix business and non-business connectors will fail DLP checks
- Cloud flows with cross-group connectors will not activate
- Solutions that include connectors in different DLP groups may fail deployment in restricted environments
Exam tip: DLP scope matters
DLP policies can be scoped to specific environments or all environments. When multiple DLP policies apply to the same environment, the most restrictive policy wins.
A common exam scenario: “A developer creates a flow that works in the dev environment but fails in production.” The answer is often that the production environment has a stricter DLP policy that blocks one of the connectors.
Elena is deploying a claims processing solution to production. The solution includes a cloud flow that uses the Dataverse connector and a custom connector to an external fraud-detection API. The flow works in the dev environment but fails to activate in production. What is the most likely cause?
A developer needs to build a plug-in that reads Contact records and updates related Account records. Following the principle of least privilege, which security role configuration is correct for the plug-in's application user?
🎬 Video coming soon
Next up: Designing UX Components — choosing between canvas components, PCF code components, and client scripts for custom user experiences.