Guía de estudio — PL-400
El temario oficial de Microsoft Power Platform Developer, organizado por dominio. Marca cada punto según lo vayas repasando.
Inicia sesión para guardar tu progreso entre sesiones.
Design technical architecture
Ver resumen
Antes de escribir código, un desarrollador PL-400 debe traducir requisitos de negocio en componentes técnicos concretos: ¿esto es un plug-in, un flujo de Power Automate, un componente PCF o una integración externa? La arquitectura técnica documenta cada pieza, sus dependencias y el motivo de la elección, evitando sobre-ingeniería o soluciones frágiles.
Ver resumen
Cada componente (plug-in, conector personalizado, Azure Function, app) necesita una estrategia de identidad: usuarios interactivos vía OAuth/Microsoft Entra ID, o procesos desatendidos vía entidades de servicio o managed identities. La autorización se combina con roles de seguridad de Dataverse para limitar qué puede leer o escribir cada componente.
Ver resumen
El principio "low-code primero" del PL-400: antes de programar, evalúa si reglas de negocio, flujos de Power Automate, vistas o columnas calculadas ya resuelven el requisito sin código. Escribir un plug-in o componente personalizado solo se justifica cuando la plataforma no ofrece esa capacidad de forma nativa.
Ver resumen
La misma lógica de negocio se puede implementar en distintas capas: reglas de negocio (declarativas, ligeras), scripting cliente (validaciones de UI), plug-ins server-side (síncronos, transaccionales) o Power Automate (asíncrono, orquestación). Elegir la capa correcta afecta rendimiento, capacidad de mantenimiento y si la lógica se aplica también fuera de la interfaz.
Ver resumen
Standard tables almacenan datos dentro de Dataverse; virtual tables exponen datos externos como si fueran nativos sin duplicarlos; elastic tables están pensadas para volúmenes altos y datos semi-estructurados (telemetría, logs); los conectores acceden a datos externos bajo demanda sin modelarlos como tabla. La elección depende de volumen, latencia y necesidad de relaciones.
Ver resumen
Las políticas DLP pueden bloquear que un flujo combine conectores de distintos grupos (por ejemplo, SQL con HTTP), rompiendo integraciones ya construidas. Los roles de seguridad, equipos, unidades de negocio y el uso compartido de filas determinan qué registros puede ver o modificar un componente en tiempo de ejecución, no solo el usuario.
Data loss prevention policies ↗Security concepts in Dataverse ↗
Design solution components
Ver resumen
Los componentes canvas (bloques reutilizables dentro del editor low-code) y los componentes PCF (code components, escritos en TypeScript) resuelven necesidades distintas: los primeros para lógica/UI reutilizable entre apps canvas, los segundos cuando se necesita control total del DOM, rendimiento o integración con librerías JS externas, incluso en apps model-driven.
Ver resumen
Un conector personalizado envuelve una API REST (propia o de terceros) en una definición OpenAPI para que Power Apps y Power Automate puedan consumirla como cualquier conector nativo. Diseñarlo implica decidir autenticación, operaciones expuestas y cómo se agrupan para no chocar con políticas DLP.
Ver resumen
Las funciones de Power Fx en Dataverse permiten extender columnas calculadas con lógica reutilizable; los plug-ins ejecutan código C# síncrono ante eventos de la plataforma; las custom APIs definen operaciones a medida invocables como mensajes de la Web API, con contrato de entrada/salida propio.
Ver resumen
Diseñar un flujo en lugar de codificarlo tiene sentido cuando la lógica es principalmente orquestación entre sistemas (esperar, aprobar, notificar) más que cómputo intensivo. El diseño debe considerar manejo de errores, concurrencia y qué parte de la lógica conviene delegar a un plug-in o Azure Function en vez de al propio flujo.
Ver resumen
Las integraciones salientes (outbound) suelen usar Service Endpoints/Webhooks o Azure Service Bus para notificar a sistemas externos cuando cambia un registro; las entrantes (inbound) usan la Web API, custom APIs o conectores para que sistemas externos escriban en Dataverse. La elección depende de si necesitas respuesta síncrona o desacoplamiento.