Study guide — PL-400
The official Microsoft Power Platform Developer syllabus, organized by domain. Check off each point as you review it.
Inicia sesión para guardar tu progreso entre sesiones.
Design technical architecture
Ver resumen
Before writing any code, a PL-400 developer needs to translate business requirements into concrete technical building blocks: is this a plug-in, a Power Automate flow, a PCF component, or an external integration? The technical architecture documents each piece, its dependencies, and the reasoning behind the choice, steering clear of over-engineering or fragile solutions.
Ver resumen
Every component (plug-in, custom connector, Azure Function, app) needs an identity strategy: interactive users authenticate via OAuth/Microsoft Entra ID, while unattended processes rely on service principals or managed identities. Authorization then layers on top through Dataverse security roles that constrain what each component can read or write.
Ver resumen
The PL-400 'low-code first' principle: before writing custom code, check whether business rules, Power Automate flows, views, or calculated columns already solve the requirement without it. Building a plug-in or a custom component is only justified when the platform has no native way to deliver that capability.
Ver resumen
The same business logic can live in different layers: business rules (declarative, lightweight), client-side scripting (UI validation), server-side plug-ins (synchronous, transactional), or Power Automate (asynchronous orchestration). Picking the right layer affects performance, maintainability, and whether the logic also applies outside the UI.
Ver resumen
Standard tables store data inside Dataverse; virtual tables surface external data as if it were native without duplicating it; elastic tables are built for high-volume, semi-structured data such as telemetry or logs; connectors reach external data on demand without modeling it as a table at all. The right choice depends on volume, latency, and whether you need relationships.
Ver resumen
DLP policies can block a flow from combining connectors from different groups (say, SQL alongside HTTP), breaking integrations that already exist. Security roles, teams, business units, and row-level sharing determine which records a component can see or change at runtime — not just what the signed-in user can do.
Data loss prevention policies ↗Security concepts in Dataverse ↗
Design solution components
Ver resumen
Canvas components (reusable building blocks inside the low-code editor) and PCF code components (written in TypeScript) solve different problems: the former for UI/logic shared across canvas apps, the latter when you need full control of the DOM, better performance, or integration with external JS libraries — even inside model-driven apps.
Ver resumen
A custom connector wraps a REST API — your own or a third party's — in an OpenAPI definition so Power Apps and Power Automate can consume it like any built-in connector. Designing one means deciding on authentication, which operations to expose, and how to group them so they don't collide with DLP policies.
Ver resumen
Power Fx functions in Dataverse extend calculated columns with reusable logic; plug-ins run synchronous C# code in response to platform events; custom APIs define bespoke operations invocable as Web API messages, each with its own input/output contract.
Ver resumen
Designing a flow instead of writing code makes sense when the logic is mostly cross-system orchestration — waiting, approving, notifying — rather than heavy computation. The design should account for error handling and concurrency, and decide which parts are better delegated to a plug-in or Azure Function instead of living inside the flow itself.
Ver resumen
Outbound integrations typically use Service Endpoints/Webhooks or Azure Service Bus to notify external systems when a record changes; inbound integrations use the Web API, custom APIs, or connectors to let external systems write into Dataverse. The choice comes down to whether you need a synchronous response or looser decoupling.