The PL-400: Microsoft Power Platform Developer exam sits at an interesting crossroads. It's a developer certification — there's real C#, JavaScript, and TypeScript in scope — but its guiding philosophy is that you should reach for code last, not first. Pass it and you've proven you can extend the Power Platform responsibly: knowing when configuration is enough, and when a plug-in, a custom connector, or an Azure Function is the right tool. These are my field notes, reorganised around how the exam actually thinks.
The five skill areas at a glance
PL-400 is organised into weighted domains. The single biggest one — extending the platform with code — is where most of your hands-on practice should go:
Create a technical design
Architecture, auth strategy, and deciding whether out-of-the-box features can meet a requirement before any code is written.
Build solutions
Environments, solutions, environment variables, layers, Pipelines, and ALM with source control.
Power Apps improvements
Advanced canvas features, complex Power Fx, reusable component libraries, and performance tuning.
Extend the UX
Client scripting against the Client API, command bar customisation, and building PCF code components.
Extend the platform
The heavyweight: Dataverse plug-ins, custom APIs, custom connectors, Azure Functions, and cloud flows.
Develop integrations
Publishing and consuming Dataverse events, and synchronising data with change tracking and upserts.
"Extend the platform" is roughly a third of the exam — weight your hands-on time accordingly.
Design first: authentication and authorization
A surprising amount of PL-400 is design judgement, and it starts with identity. Two words that sound alike but mean different things:
- Authentication — proving who you are. The Power Platform uses Microsoft Entra ID; users sign in with their tenant credentials. For system-to-system integrations you register an app in Entra ID and add a server-to-server (S2S) account so an external system can reach Dataverse. When you call out to Azure or third-party services, you typically authenticate with OAuth 2.0.
- Authorization — deciding what you're allowed to do. Access to an environment is gated by Entra ID security groups; access to resources within it is governed by Dataverse security roles plus record sharing.
Configure before you code
This is the mantra the whole exam is built on: treat writing code as the exception, not the default. Many requirements are met entirely with platform features, and the exam loves to check that you know them — and their limits.
| Feature | How it behaves | Good to remember |
|---|---|---|
| Calculated columns | Computed on retrieve. | Can use columns on the row and across many-to-one relationships. |
| Formula columns | Computed on retrieve, powered by Power Fx. | Wide range of Power Fx functions; limited support for currency columns. |
| Rollup columns | Aggregated on a schedule (recalculated roughly hourly). | Need a one-to-many relationship; max 100 per environment, 10 per table; supports hierarchies. |
| Business rules | Declarative validation and logic on forms and server-side. | Often remove the need for JavaScript on model-driven forms. |
A key nuance the exam probes: client scripting reacts immediately as a user leaves a field, whereas calculated and formula columns only update on retrieve — so a freshly typed value won't reflect in a calculated column until the data is reloaded. And when a configured feature falls short, the fallbacks are themselves worth knowing: business rules, client script (JavaScript), real-time workflows, plug-ins, and Power Automate cloud flows can stand in for calculated/formula columns, while plug-ins and cloud flows can replace rollups. A cloud flow can even cascade changes down a one-to-many relationship — pushing a changed address from an account to all its contacts, for instance.
Where should the logic live?
The most exam-critical decision you'll make repeatedly: given a requirement, which extensibility point runs the logic? This comparison is the heart of it:
| Capability | Power Automate cloud flow | Dataverse plug-in | Client scripting |
|---|---|---|---|
| Sync / async | Asynchronous | Either | Synchronous |
| External data | Yes, via connectors | Yes, via APIs | Yes, with limits |
| Maintained by | Makers | Developers | Developers |
| Runs on demand | Yes | No | No |
| Execution stage | After | Before / after | Before / after |
| Triggers | Create, change, delete, on-demand, scheduled | Create, change, delete + many other messages | Column change or form load/save |
And when the work is heavier or longer-running, the choice widens to serverless. The trade-off between a plug-in and an Azure Function comes up often:
- Dataverse plug-in — event-driven only (it can't be scheduled), authenticated automatically in-platform, but bound by a 2-minute execution limit.
- Azure Functions — a 5-minute default on the Consumption plan (raisable to 10; longer on Premium/Dedicated), Durable Functions for chaining long operations, but you must handle authentication yourself.
The plug-in execution pipeline
If you take one diagram into the exam, make it this one. A Dataverse plug-in is registered against a message (Create, Update, etc.) and runs at a particular stage. Pre/Post Images let you see the row's values before and after the operation:
Register on the right stage: change inputs in pre-operation; act on the saved record in post-operation.
Other "extend the platform" essentials: develop plug-ins against the execution context, talk to data through the Organization service, register everything with the Plug-in Registration Tool, and expose reusable server logic as a custom API message. For outbound work, you can publish Dataverse events to webhooks, Azure Service Bus, or Azure Event Hubs — Service Bus is asynchronous and queueable, while a webhook is an HTTP call that depends on the endpoint being available and can run synchronously.
PCF: the Power Apps component framework
PCF lets developers build reusable, rich UI controls in HTML, CSS, and TypeScript, package them as solutions, and drop them into model-driven apps, canvas apps, and Power Pages. There are three component types — a field control (one column on a form), a dataset control (a custom grid/subgrid), and a control that surfaces content from external services.
The exam expects you to know the component lifecycle methods cold:
| Method | When it runs & what it's for |
|---|---|
| init | Initialises the component; kick off remote calls here. Note: dataset values aren't available yet — use updateView for those. |
| updateView | Called whenever a value in the component's property bag changes. |
| getOutputs | Optional. Called before new data is received; use it to manage bound properties. |
| destroy | Runs when the component leaves the DOM. Clean up and release memory here. |
Solutions and ALM
Solutions are the containers that move your work between environments — the backbone of application lifecycle management. The classic path runs Dev → Test → Production:
Development
Unmanaged solution; author and edit
Test
Managed solution; validate in isolation
Production
Managed solution; deploy to users
Unmanaged while you build; managed everywhere downstream.
The distinction matters on the exam: unmanaged solutions are for development and moving work between dev environments; managed solutions are for distributing to non-dev environments. A few more points that come up:
- Solution components are tracked items — tables, apps, flows, security roles, developer assets. Some are sub-components (forms, views, charts, and columns belong to a table). Reference data is not a solution component.
- Environment variables externalise per-environment config (a sender email, a portal URL) so flows aren't hard-coded; they ship as solution components with optional default values overridable per environment, and don't require a Dataverse license to consume.
- Solution layers stack managed solutions under a single unmanaged (active) layer — and note that simply editing, or even testing, a managed flow without saving creates an unmanaged layer that can mask the managed behaviour until you delete the active layer.
Automating the pipeline
You're expected to know the spectrum of automation tooling and when each fits:
- Power Platform Pipelines — the low-friction starting point for straightforward deployments, with approvals/gating and the ability to redeploy previous versions. Personal pipelines target developer environments; Standard pipelines need Managed Environments (premium licensing).
- Source control (Git on Azure DevOps or GitHub) — version your solutions and code, unpack solutions with the Power Platform CLI (the recommended tooling) or SolutionPackager, and mind your
.gitignore. - Power Platform CLI (
pac) — command-line automation for every part of a deployment. - Power Platform Build Tools — Azure DevOps pipeline tasks (built on the CLI) for more complex scenarios, at the cost of some YAML expertise.
Dataverse, the data backbone
Underneath all of this is Dataverse — an API-first, secure, low-code data platform. Know the three table types: standard (create and edit rows), activity (track time-bound interactions like emails, phone calls, and tasks — and remember all activities share one set of security privileges), and virtual (surface external data as Dataverse tables without copying it). Server-side logic and validation come from business rules, business process flows (model-driven only), classic workflows, and code.
Integrations and the platform APIs
Finally, you interact with Dataverse two main ways, and the exam wants you to pick correctly:
- Web API — an OData 4.0 / REST endpoint, ideal from non-.NET clients and modern web/JavaScript scenarios.
- Organization service — the .NET SDK path, the natural choice inside plug-ins and custom workflow activities.
For data synchronisation, lean on change tracking to pull only what's changed, alternate keys to reference rows by a natural business key, and the UpsertRequest message to insert-or-update in one call. When you build custom connectors, you'll create an OpenAPI definition, implement authentication, optionally wrap an Azure service or Function, and use policy templates to reshape runtime behaviour. And across all API work, design for retry policies, concurrency, bulk operations, and OAuth.
The takeaway
PL-400 rewards a particular instinct: reach for configuration first, understand exactly where the platform's declarative features stop, and only then choose the right code-based extension — a business rule, a cloud flow, a plug-in on the correct pipeline stage, a PCF control, or an Azure Function. Pair that judgement with solid ALM hygiene (solutions, environment variables, layers, source control) and a working knowledge of the Web API versus the Organization service, and the heavyweight "extend the platform" domain stops being intimidating. Study the scenarios, get hands-on in a developer environment, and let the configure-before-code mindset guide every answer.