PL-400 is still a live Microsoft Power Platform Developer exam on October 4, 2026, but it is in a short transition window. Microsoft has announced that registration for PL-400 closes on October 16, registration moves to AB-400, and candidates who register for PL-400 by that date can continue to schedule and take PL-400 through October 30. The current PL-400 exam page still lists the pre-transition blueprint as the live assessed structure.
That live PL-400 structure is: Create a technical design 10–15%, Configure Microsoft Dataverse 15–20%, Create and configure Power Apps 10–15%, Extend the user experience 10–15%, Extend the platform 35–40%, and Develop integrations 5–10%. Microsoft requires a passing score of 700. The updated October 16 study guide reorganizes the skills for the future transition and should not be blended into a pre-October-16 exam plan.
PL-400 is a developer exam, not a maker fundamentals exam
Microsoft describes the candidate as someone who designs, develops, tests, secures, and troubleshoots Power Platform solutions using extension points. Expected experience includes JavaScript, JSON, TypeScript, C#, HTML, RESTful Web APIs, Power Platform services, and Azure.
A Power Platform Developer preparation plan should therefore include real coding and Dataverse extension work, not only canvas-app design or flow templates.
Create a technical design is 10–15%
The design area covers analyzing requirements, choosing solution components, identifying where low-code is sufficient, selecting extension points, designing security and authentication, considering integration and ALM, and deciding where business logic should run.
The key skill is placement: client script, Power Fx, cloud flow, plug-in, custom connector, Azure service, or another extension can all implement logic, but they have different performance, security, lifecycle, and maintenance implications.
Configure Microsoft Dataverse is 15–20%
Dataverse is the platform core for data, metadata, security, business logic, events, and APIs. Developers should be comfortable with tables, columns, relationships, alternate keys, security, solutions, environment variables, and how Dataverse behavior changes across managed or unmanaged solution layers.
The developer perspective goes beyond creating a table: schema and security choices affect plug-ins, client scripts, integrations, flows, and deployment.
Create and configure Power Apps is 10–15%
This area covers building and extending canvas or model-driven experiences and applying developer skills where low-code features need enhancement. The developer should understand how app components interact with Dataverse, connectors, business logic, and lifecycle management.
An understanding of Power Apps is assumed, but PL-400 expects extension depth rather than beginner maker skills.
Extend the user experience is 10–15%
Client scripting and Power Apps Component Framework are central here. Developers should understand the model-driven Client API, event handlers, Dataverse Web API calls from client code, commands/buttons, navigation, dialogs, notifications, and PCF component lifecycle and packaging.
PCF exists when standard controls or low-code components cannot meet the user-experience requirement cleanly.
Extend the platform is the largest domain at 35–40%
The largest live domain includes Dataverse plug-ins, custom APIs, platform APIs, Organization Service, Dataverse Web API, authentication, API-limit handling, Azure Functions, Power Automate cloud flows, custom connectors, and integration patterns around Dataverse events.
This weighting is the clearest signal that PL-400 is about extending the platform through code and services, not simply configuring Power Platform features.
Plug-ins and server-side logic are high-value skills
Developers should understand Dataverse event pipeline stages, execution context, entity images, synchronous versus asynchronous considerations, performance, transaction behavior, registering plug-ins, and designing custom APIs or business events.
The exam can test why server-side logic is preferable when validation must occur regardless of which client calls Dataverse.
Develop integrations is 5–10%
The integration area covers publishing and consuming Dataverse events, webhooks or Azure messaging endpoints, change tracking, alternate keys, upsert, and custom connectors. The developer should understand reliable synchronization and how external systems exchange data with Dataverse.
Integration questions often test consistency, retry, duplicate handling, authentication, and which platform event or API should be used.
The PL-400 to AB-400 transition is a real date boundary
The future October 16 outline collapses and reorganizes domains, adds modern code-app and agentic AI content, expands user-experience weight, and raises integration weight. Those changes are relevant for AB-400 or PL-400 appointments using the new transition version, but an October 4 candidate should prepare against the live assessed PL-400 structure shown on Microsoft’s exam page.
A PL-400 skills plan should therefore be explicitly dated. Do not mix pre-transition and post-transition percentages in the same final notes.
Current preparation should prioritize extension depth and timing
Spend the most time on plug-ins, APIs, custom connectors, Power Automate expressions, client scripting, PCF, Azure Functions, ALM, and Dataverse design. Then confirm the exact appointment date and registration status because the exam’s transition window is unusually short.
The transition timing creates an unusual situation: Microsoft’s study-guide page already exposes the October 16 reorganization, while the PL-400 exam page still identifies the older live skill groups. Candidates testing before the registration transition should therefore anchor their preparation to the currently assessed exam page and use future material only to understand what is changing next.
The certification role itself is broader than the old percentages suggest. Microsoft’s current developer-associate page now mentions complex Power Fx, Power Automate expressions, Power Platform CLI, AI tools, and modern IDEs. Those capabilities are relevant to real work and to the transition, but the pre-October-16 PL-400 exam still reports its legacy domain structure.
Technical-design questions often revolve around boundaries. Client-side code can improve form behavior but should not enforce a critical rule by itself. Plug-ins can enforce Dataverse-side logic but may not be appropriate for a long-running external calculation. Power Automate provides orchestration, while Azure Functions provide code execution outside the Dataverse transaction.
Authentication and authorization should be part of design from the start. External integrations may use OAuth, service principals, managed identities, or other supported patterns depending on the component. The developer should avoid embedding user credentials or secrets in code and should scope privileges to the operations actually required.
Dataverse solution architecture also includes standard versus custom tables, choice of relationships, alternate keys, virtual-table patterns where applicable, and data ownership. A poor table design can create performance or integration problems that no amount of client scripting can fix later.
Solution layers and dependencies matter because Power Platform customizations can come from Microsoft, managed solutions, unmanaged development work, or patches/upgrades. Developers should know which layer owns the effective component and avoid changes that create unexpected dependency or upgrade conflicts.
Environment variables and connection references help separate configuration from solution logic. A flow or integration should not require editing hardcoded development URLs or credentials after import into test or production. ALM succeeds when environment-specific values are injected through supported configuration.
Power Apps development in PL-400 assumes more than creating controls. Developers may need to optimize formulas, manage delegation constraints, work with custom components, and integrate client-side or server-side behavior. The exact live domain wording is older, but the expected practitioner level remains technical.
Client API code should be written defensively because forms can change, fields can be missing, and asynchronous calls can fail. Registering event handlers deliberately and keeping JavaScript modular makes model-driven extensions easier to test and support than a large script attached to every form event.
PCF components should expose clearly defined inputs and outputs and use platform services rather than bypassing the app model unnecessarily. Packaging the component in solutions allows controlled deployment. The developer should weigh the benefit of custom interaction against the maintenance burden of custom code.
Plug-in performance is critical because synchronous logic can delay user transactions. Developers should avoid unnecessary service calls, large queries, or recursive updates and should move long-running or noncritical processing to asynchronous patterns when appropriate.
Custom APIs can provide a governed Dataverse operation that clients or integrations invoke consistently. They are useful when a business operation is more meaningful than a sequence of raw table updates and when server-side validation should remain centralized.
API-limit handling is another practical developer skill. Dataverse can throttle requests under heavy load, so integrations should implement retry patterns and avoid inefficient row-by-row operations when batch or bulk approaches are available. Correctness without scalability can still produce a failing production solution.
Azure Functions can process work that does not belong inside a Dataverse plug-in transaction, such as scheduled integration, external API orchestration, or longer-running processing. The developer should still design authentication, retry, telemetry, and idempotency because moving logic to Azure does not remove failure modes.
Power Automate expressions and error handling matter in developer-grade flows. Complex conditions, retry policies, child flows, trigger filters, and service-principal authentication can turn a maker-style workflow into a reusable solution component. The exam may present a flow that requires more discipline than a simple notification.
Dataverse event integrations should be designed for eventual failure. Webhooks, Service Bus, or Event Hub endpoints may be unavailable temporarily; consumers may receive duplicate or delayed messages; and data may change between event publication and processing. Reliable integrations anticipate these conditions.
Change tracking and alternate keys help synchronization with external systems. A stable alternate key lets an integration find the same business record across systems, while change tracking reduces the need to query every row. Upsert can simplify create-or-update behavior when the external identifier is reliable.
Custom connectors wrap existing APIs for use in Power Apps and Power Automate. A good connector defines authentication, operations, request/response schemas, and policy behavior clearly. It should not be used to hide a poorly designed API that lacks stable contracts or error semantics.
Final preparation should be conservative with version drift. If the exam appointment is before October 16, keep the old percentages and old skill-group names. If the appointment is between October 16 and October 30 under a valid PL-400 registration, verify Microsoft’s latest instructions because the published study guide is changing into the future AB-400 model.
Within the wider Microsoft certification portfolio, PL-400 still validates Power Platform developer skills today, but AB-400 is the immediate next form of that developer credential. Status awareness is part of responsible preparation in October 2026.