PL-400 Microsoft Power Platform Developer Study Guide¶

Independent AI-assisted resource — HUMAN REVIEW PENDING. The October 28, 2026 team refresh reconciles the complete guide and detailed objectives with current public exam, product and learning evidence. See the current group report and the sources-and-objectives record. Known source conflicts and unexecuted exercises remain explicit. This is not human review or live product validation. The official blueprint is authoritative.

Study guide at a glance

Start here

Report an issue with PL-400

Blueprint checked2026-10-28

Review stateSources + objectives checked — human review pending

Guide-only active reading1 hr 30 min–2 hr

Prerequisites: Hands-on Power Platform development across Dataverse, model-driven and code apps, Power Automate and solutions; Power Fx, JavaScript/TypeScript, C#, Python, HTML, JSON and YAML; REST/OData, OpenAPI, Azure, Foundry, Copilot Studio, identity, security, ALM, testing and troubleshooting. Match implementation APIs to the actual client and installed SDK.

Exam essentialsRead the objective map, key distinctions, and readiness checklist.

Deep understandingWork through every domain, including decisions, failure modes, and related items.

Hands-on labsBegin with Lab 1 — Architecture and security decision, then use the remaining labs to produce evidence you can inspect and explain.

Official objective domains

See the objective map in this guide

The active-reading range uses 90–130 words per minute for technical material. Labs, troubleshooting, note-taking, spaced review, and prerequisite gaps add time; it is not a total preparation promise.

Current published baseline: Skills measured as of October 16, 2026. The earlier March snapshot and six-domain weights are historical.
Exam transition — VERIFY CURRENT (October 28, 2026): PL-400 registration closed October 16. Existing registrations can still schedule/take PL-400 through October 30. AB-400 is available for new registrations. The credential notice and AB-400 blueprint define the transition. The current PL-400 page publishes the October 16 four-domain outline; this refresh accepts and maps that published text while preserving March as history. This does not create a separate complete AB-400 guide or establish identical delivery for an existing PL-400 appointment.
Official source: PL-400 study guide Practice routing — VERIFY CURRENT (October 28, 2026): The credential page routes Practice Assessment to AI Skills Navigator with sign-in. No assessment was launched or its question content inspected. Recheck the vendor launch route before relying on an older direct link below; a practice result does not establish coverage of another exam code.

How to use this guide¶

PL-400 is about choosing and implementing the correct Power Platform extension point. Memorizing product names is not enough: a sound answer respects the data, identity, transaction, performance, deployment, and support boundaries of the requirement. For every solution, trace:

the business operation, caller, data owner, volume, latency, and failure consequence;
what can remain out of the box and why code is justified;
the client, Dataverse transaction, flow, connector, function, or event boundary;
the user, application, or managed identity and its least-privilege authorization;
synchronous versus asynchronous execution, limits, retry, idempotency, and observability;
solution components, dependencies, environment configuration, source control, and deployment route;
unit, integration, security, performance, failure, and rollback evidence.

Work the ten labs or tabletop unavailable capabilities and answer all 44 original checks. No live tenant labs were executed for this review.

The current audience is an experienced developer using Power Fx, JavaScript/TypeScript, C#, Python, HTML, JSON and YAML, with Azure, Foundry and Copilot Studio. Build in a disposable developer environment and recognize REST/OData, OpenAPI and pipeline configuration. Language familiarity does not establish SDK feature parity.

About related items: A Related item: callout adds prerequisite, operational, architectural, or adjacent context that makes the current topic easier to understand. It is useful supporting knowledge, not a claim that the item appears verbatim in the published exam objectives.

Current published four-domain outline and AB-400 transition¶

The AB-400 blueprint covers Extending Microsoft Power Platform Solutions with Code and AI. The PL-400 page now publishes the same four domain weights shown here. Keep that current source observation, the historical six-domain foundation, the remaining PL-400 appointment window and new AB-400 registration separate.

Current published area (paraphrased)	Weight	Existing foundation and extension
Building platform solutions	15–20%	Reuse design, security and ALM; add AI-assisted development and deterministic-versus-agentic decisions
Extending experiences	25–30%	Reuse scripts/PCF; compare code apps, generative pages, interactive agents and MCP app widgets
Extending the platform	35–40%	Reuse plug-ins, automation and service boundaries; study agent integration and current platform extension points
Integrations	10–15%	Reuse identity, API, event and synchronization reasoning; recheck the complete replacement objective list

Original design exercise: extend a customer-service solution with an assistant that proposes a case update. Identify the component allowed to suggest text and the component responsible for validating and committing a record change. Specify authorization, schema checks, idempotency, timeout handling and audit evidence; exercise a duplicate request and a rejected update. Explain why plausible generated text cannot substitute for transaction validation. Map the resulting design to the AB-400 blueprint before treating this PL-400 guide as sufficient AB-400 preparation.

Historical March objective organization¶

Published domain	Weight	Central question
Create a technical design	10–15%	Which platform, code, identity, data, and integration boundaries satisfy the requirement?
Build Power Platform solutions	10–15%	Can the solution be developed, secured, packaged, promoted, and diagnosed safely?
Implement Power Apps improvements	10–15%	Can advanced canvas/model-driven behavior remain correct, reusable, and performant?
Extend the user experience	10–15%	Should the experience use client scripting, commands, custom pages, or PCF?
Extend the platform	30–35%	Can server logic, connectors, APIs, Functions, and flows operate reliably at scale?
Develop integrations	10–15%	Can events and synchronized data cross boundaries without loss or duplication?

1. Create a technical design¶

Start with requirements and the smallest sufficient extension¶

Translate a request into actors, data classification, operation, timing, volume, availability target, ownership, licensing, and acceptance evidence. Then test whether standard tables, forms, views, business rules, Power Fx, Power Automate, built-in connectors, and platform configuration already meet it. Custom code creates a versioning, security, telemetry, and support obligation; use it when that obligation buys a required capability.

The Dataverse plug-in guidance explicitly recommends declarative business logic first when it satisfies the requirement. “Low-code” and “pro-code” are not competing goals. A good design keeps business meaning visible in the platform while using code for boundaries the platform cannot express safely or efficiently.

Extension location	Strong fit	Avoid or reconsider when
Business rule / formula	Immediate, maintainable validation or calculation supported declaratively	Logic needs unsupported data, transaction control, or complex reuse
Canvas Power Fx	App-specific interaction and user-visible calculation	The rule must hold for imports, APIs, flows, and every other client
Client script / command	Model-driven form behavior, navigation, and command interaction	The rule is a security boundary or must run for noninteractive callers
Synchronous plug-in	Short server-side validation or mutation that must share the Dataverse transaction	Work is slow, calls an unreliable remote dependency, or can finish later
Asynchronous plug-in / event	Post-commit work where user response need not wait	The caller requires an immediate atomic result
Cloud flow	Orchestration, connectors, approvals, and maintainable asynchronous automation	Tight transaction semantics or high-throughput low-latency processing is required
Custom API	A named Dataverse operation/contract backed by server logic	Ordinary CRUD or an existing action already represents the operation
Custom connector	A reusable Power Platform facade over an API	No stable API contract exists or direct Dataverse access is sufficient
Azure Function	Long-running, scheduled, compute-heavy, event-driven, or isolated code	A short in-transaction Dataverse rule is required

Choose the data access shape¶

Standard Dataverse tables provide the normal relational, security, API, and extensibility model. Virtual tables expose external data through Dataverse without copying it, but their provider capabilities and supported platform behaviors must meet the use case. Elastic tables target very large/high-throughput workloads with different behavior and limitations. A connector invokes an external service rather than making it a Dataverse table.

Do not choose from the nouns alone. Prove create/read/update/delete support, query/filter behavior, relationships, transactions, security, auditing, offline requirements, retention, latency, volume, ownership, and failure recovery. VERIFY CURRENT: virtual and elastic table capabilities, licensing, limits, and supported APIs change more quickly than the core standard-table model.

Design identity, authorization, and governance together¶

Identify whether each call runs as the interactive user, a Dataverse application user/service principal, or a managed identity. Authentication proves the caller; authorization decides what that caller may do. Configure security roles for the minimum table privileges, scope, and special privileges required by the component. Consider teams, business units, ownership, sharing, field security, and hierarchy behavior rather than assuming a role name explains effective access.

DLP policies classify connectors into business, nonbusiness, or blocked groups and constrain which data paths can coexist in an app or flow. DLP is an environment/tenant governance boundary, not a replacement for API authorization or Dataverse row security. Capture the expected policy, connector classification, environment routing, and exception process in the design before development.

Related item: Threat modeling makes the component diagram operational. Mark trust boundaries, secrets, tokens, personal data, privileged operations, untrusted input, outbound destinations, logs, and support access; then attach a test or control to each risk.

Design reusable components and integrations¶

Use a canvas component/component library for reusable maker-owned UI and formulas. Use PCF for a packaged TypeScript component that must integrate with the Power Apps runtime, data set, device, utility, or Web API features. Use client scripting for model-driven form and command behavior. Keep a public input/output contract and avoid embedding environment-specific identifiers.

For every connector, custom API, plug-in, flow, Function, webhook, Service Bus endpoint, or Event Hubs consumer, specify:

request/event schema, version, owner, authentication, authorization, and secret/certificate rotation;
synchronous or asynchronous contract, timeout, retry, idempotency key, ordering, duplicate handling, and poison-message path;
data classification, DLP impact, region/residency, encryption, logging redaction, and retention;
expected rate/burst/payload, service limits, cost, availability, telemetry, alert, and replay/reconciliation procedure.

Power Fx functions in Dataverse package named input/output parameters, referenced tables, and server-side Power Fx in a solution. They can expose reusable business operations without C#, but the feature remains preview in the current documentation. Test supported functions, delegation, invocation, security, ALM, deletion/upgrade, and error behavior; do not propose a preview dependency for production without explicit risk acceptance. VERIFY CURRENT: name, authoring surface, supported formula set, invocation, and production-support status.

Do not copy canvas formulas unchanged into server functions. The supported Power Fx table excludes Concurrent, ClearCollect and Defaults; it describes Collect as an alternative for particular create scenarios. These operations run in a transaction context. Test the supported formula subset and failure/rollback behavior independently of a successful canvas formula.

2. Build Power Platform solutions¶

Environments and operational security¶

Give each developer appropriate isolation, then promote through test and production rather than building directly in production. Decide environment type, Dataverse database, region, security group, capacity, tenant settings, DLP, developer access, and service connections. Make environment configuration reproducible and keep privileged administrative access separate from component runtime identities.

Troubleshoot access from evidence: caller identity, environment, app sharing, license, security roles, team/business-unit scope, record owner/share, field security, connector connection, flow run-only user, application-user mapping, and DLP. “Works for the maker” often means the component is accidentally borrowing maker permissions or a personal connection.

Solutions, configuration, dependencies, and layers¶

Develop in an unmanaged solution and deploy managed artifacts downstream unless an explicit lifecycle model justifies otherwise. Include apps, flows, tables, web resources, plug-in assemblies/steps, custom APIs, PCF components, connection references, and other dependencies deliberately. Use connection references for solution-aware connector bindings and environment variables for nonsecret environment-specific configuration. Keep secrets in an appropriate secret store, not in environment-variable default values or source control.

A dependency says one component requires another. Inspect dependencies before removing or splitting components; avoid adding every object “just in case.” A solution layer records how system, managed, unmanaged, and active customizations combine. Use the solution layers view to explain which layer currently wins before deleting, upgrading, or applying an unmanaged change.

Related item: A managed solution is a deployment unit, not automatically a complete rollback plan. Record data migrations, connector/API compatibility, plug-in step changes, environment-variable values, flow ownership, and the tested recovery action for each release.

Pipelines and CI/CD¶

Personal pipelines using the platform host provide deployment validation and environment-specific configuration handling, but cannot be extended or shared. They support one development and two target environments; targets must be Managed Environments and every participating environment needs Dataverse. Requirements for extensions, shared pipelines or additional stages call for a custom host design. Deleting a personal pipeline alone does not remove its host environment associations. Power Platform Build Tools provide Azure DevOps tasks for solution export/unpack/check/build/import and related operations; use a service connection with least privilege and protect credentials.

A defensible pipeline should:

authenticate noninteractively without a developer's personal credential;
export/unpack and version the solution plus conventional C#/TypeScript/OpenAPI source;
restore dependencies, compile, lint, unit-test, and run Solution Checker or equivalent analysis;
create an immutable build artifact and deployment settings without secrets;
import into test, bind connections/environment values, activate required processes, and run smoke/integration/security tests;
require the configured approval/evidence for production, retain logs, and exercise rollback or forward-fix.

Do not confuse source control with an exported unmanaged zip sitting in a file share. The useful review surface is unpacked solution metadata plus normal source code, build instructions, dependency versions, and release evidence.

3. Implement Power Apps improvements¶

Advanced canvas apps and reusable logic¶

Power Fx is declarative where possible: formulas recalculate from dependencies. Behavior formulas sequence actions and side effects. Use With for local named values, Concurrent only for independent operations, IfError/Errors for explicit failure handling, and Patch for controlled updates. Understand records, tables, scope operators, delegation warnings, and how blank/error values propagate. Never turn an authorization decision into a client-only formula.

Component libraries distribute reusable canvas components across apps. Define narrow input/output properties, behavior properties where appropriate, accessible states, consistent styling, version/change notes, and a consumer-upgrade test. A copy-pasted component is not centrally reusable. Avoid hiding data access and side effects behind a visual abstraction that consumers cannot diagnose.

A canvas app can call a Power Automate cloud flow for orchestration. Define the request/response contract, caller versus connection identity, timeout/user feedback, safe retry, idempotency, and error payload. Long work should return a tracking identifier and complete asynchronously rather than leaving the user staring at a spinner.

Diagnose and optimize from measurements¶

Use Monitor to inspect app events, network/data operations, formula evaluation, errors, and collaboration traces; use browser developer tools for network, console, and client failures. Reproduce under the affected user's identity and representative data. Check data source response, connector throttling, delegation, payload/column size, repeated calls, control count, nested galleries, startup formulas, and unnecessary collections.

Delegable queries run at the data source over the full set. Nondelegable operations may evaluate only a configured local subset and produce a fast but incomplete answer. Resolve the warning by choosing supported predicates/functions, changing the source/query shape, or explicitly limiting the business scope—not by merely increasing the row limit. Preload only small, stable data that materially improves the interaction; indiscriminate ClearCollect increases startup cost, memory use, staleness, and delegation risk.

For model-driven apps, measure form load and interaction behavior. Reduce unnecessary columns, tabs/subgrids/quick views, synchronous client work, duplicate handlers, chatty Web API calls, and costly view filters or plug-ins. Test with real security roles because effective metadata and accessible data can change the path.

Related item: Instrumentation should connect a user-visible operation to flow runs, API/Function telemetry, Dataverse plug-in trace, and downstream messages using a correlation identifier. Without correlation, each tier can look healthy while the end-to-end operation fails.

4. Extend the user experience¶

Model-driven client script runs in a browser and uses the Client API object model. Receive the execution context and derive formContext; do not build new code around deprecated global Xrm.Page. Register handlers on the correct form/control event, pass context, avoid duplicate registration, remove handlers where required, and keep event work short. OnLoad, OnSave, attribute OnChange, form data, grid, and command contexts expose different objects and timing.

Use the Dataverse Web API asynchronously from supported client APIs. Select only required columns, encode query input, handle promise rejection and 401/403/404/409/429/server failures, and do not place secrets in browser code. Client-side logic cannot be trusted to enforce a business rule because it can be bypassed by another client or API.

Modern commands can use Power Fx for supported declarative actions and visibility. JavaScript is appropriate for supported capabilities that require client APIs or a richer behavior contract. Test command scope, selected record(s), unsaved changes/AutoSave, permissions, mobile/support surface, solution packaging, and navigation. Use supported Xrm.Navigation/client APIs to open records, pages, URLs, dialogs, and custom pages rather than manipulating implementation-detail DOM elements.

Power Apps component framework¶

A PCF manifest declares the component namespace/name, type, properties/data sets, resources, feature usage, and platform contract. The main lifecycle is:

init: retain services and initialize state; rendering may wait for data;
updateView: receive new context and render/reconcile current state;
getOutputs: return changed bound values when the framework requests them;
destroy: remove listeners and release resources.

Implement the interfaces and feature declarations that the component actually uses. Device, Utility, and Web API features depend on context and supported host. Handle disabled/visible state, resizing, loading, null/error data, accessibility, localization, themes, security, and multiple instances. Do not assume model-driven and canvas hosts behave identically.

Build/test with Power Platform CLI tooling, package the component into a solution, deploy through the normal ALM route, and consume it on a supported field/data set. Pin and scan npm dependencies, avoid exposed secrets, sanitize untrusted content, and measure rendering/network behavior. A component that works in the local harness still needs host, permission, solution-upgrade, and accessible interaction tests.

5. Extend the platform¶

Dataverse plug-ins and custom APIs¶

The Dataverse event framework processes operations through stages. Choose the stage and execution mode from the semantic requirement:

Stage/mode	Transaction position	Typical purpose	Key risk
PreValidation synchronous	Usually before the main transaction/security checks	Reject invalid operation early	Authorization/context assumptions; nested calls can already be transactional
PreOperation synchronous	Inside transaction before the core operation	Change target values atomically	Slow/error-prone work holds and can roll back the transaction
PostOperation synchronous	Inside transaction after core operation	Return/derive transaction-dependent output	Updating the same row can recurse; external calls extend transaction time
PostOperation asynchronous	After commit through async service	Notifications and eventual side effects	Duplicate/delayed work, ordering, and reconciliation

IPluginExecutionContext supplies message, stage, mode, depth, correlation/operation identifiers, user identities, input/output parameters, shared variables, and entity images. Validate type and presence before casting. A pre-image captures selected values before the operation; a post-image captures selected values afterward. Register only required columns. Images avoid needless reads but are not available for every message/stage combination.

Use the IOrganizationService created from the service provider under the intended user context. Select only needed columns and minimize operations. Avoid long external calls, unbounded queries, broad exception swallowing, recursive updates, and storing mutable transaction state in static members. Trace safe diagnostic context and throw InvalidPluginExecutionException with a useful user message for intended synchronous rejection.

Register assemblies, steps, message, primary table, stage, mode, rank, filtering attributes, images, and configuration with the Plug-in Registration Tool. Filtering attributes reduce irrelevant update executions but do not mean a value changed—compare images where that matters. Test create/update/delete, missing fields, bulk paths, alternate clients, impersonation, recursion, timeout, and rollback.

Worked example — A filtering attribute was supplied but did not change¶

An Update step filters on creditlimit. The request contains creditlimit = 5000, and the pre-image also contains 5000. The step can execute because the attribute is present; the business value is unchanged. Compare the target with the registered pre-image before producing a “limit changed” notification. If the request omits creditlimit and no other filtering attribute matches, that step is not triggered by this filter. Check image availability and filtering rules in the registration documentation.

Worked example — Database rollback cannot recall an external notification¶

A synchronous PostOperation plug-in calls an external notification API, which succeeds. A later synchronous step fails, rolling back the Dataverse operation. The external service has already acted; that call was not a Dataverse database write. A better design publishes work after commit, records an idempotency key, and reconciles eventual delivery. Use the transaction model to identify which writes actually share a transaction. Check IsInTransaction for nested PreValidation operations, and keep remote latency out of critical synchronous work.

Define custom APIs¶

A custom API defines a named action or function, binding, request/response parameters, privilege, availability, and whether custom processing is permitted. Implement its main operation with a plug-in when needed. Use a function only for a side-effect-free operation; use an action for a command that can change state. Version the contract rather than silently changing consumers. Dataverse business events expose meaningful operations to subscribers; define their stable payload and lifecycle.

Custom connectors and OpenAPI¶

Start from a stable REST API and describe operations, parameters, schemas, responses, and security in OpenAPI. The current custom-connector import route requires OpenAPI 2.0 and a definition smaller than 1 MB; it does not accept an arbitrary OpenAPI 3.0 file. Its OAuth security-definition flow does not support client credentials. A service principal supported by the Dataverse connector does not establish the same support for every custom connector. Import from a definition, Azure service, or GitHub when appropriate, then add Power Platform-specific metadata/extensions. Configure OAuth 2.0/Microsoft Entra ID, API key, or supported authentication from the API's security model; never invent client-side secrecy.

Policy templates can route a request, set/remove values, or transform supported runtime behavior. Custom connector code can perform transformations that policy templates cannot, but adds a code-review and runtime boundary. Neither should conceal an unstable or unsafe API. Test token acquisition/refresh/consent, least privilege, paging, optional/null fields, multiple responses, throttling, timeouts, localization, DLP classification, connection ownership, sharing, and deployment across environments.

An Azure Function can expose an API behind a custom connector. Authenticate the caller, validate input, authorize the operation, protect secrets, and return a documented error schema. Separate the connector contract from the Function implementation so each can version deliberately.

Platform APIs, performance, and reliability¶

Use the Dataverse Web API for REST/OData clients and the current Dataverse SDK/Organization service for .NET clients. Request only required columns, filter server-side, page correctly, and use optimistic concurrency when conflicting writes matter. Choose a bulk or transaction request only when its semantics, partial-failure behavior, and limits fit the business operation; batching is not permission to hide unbounded work.

Dataverse service protection limits can return HTTP 429/SDK faults. Respect Retry-After, cap retries, add jitter where appropriate, and make replay safe. Gradually tune concurrency against telemetry rather than hard-coding a remembered platform limit. VERIFY CURRENT: service limits and client-library retry behavior can vary or change.

OAuth clients need the correct tenant, environment resource/audience, app registration, flow, scopes/permissions, consent, token cache, and secret/certificate/federated credential lifecycle. Treat 401 (authentication/token) differently from 403 (authenticated but unauthorized). Log correlation and outcome, not tokens or sensitive request bodies.

Current plug-in outbound identity: Power Platform managed identity setup recommends version 2 for new and existing plug-ins. It hashes the full certificate distinguished names for federation instead of relying on version 1 common-name formatting. Plan the signed assembly/package, federated credential, Dataverse managed-identity record and binding, resource permission, and integration test. Self-signed certificates are for development/testing. This outbound plug-in identity is a different configuration from an Azure Function authenticating inbound to Dataverse as an application user.

Azure Functions and cloud flows¶

Move long-running, scheduled, compute-intensive, or event-driven work outside a synchronous Dataverse transaction. Choose HTTP, timer, Service Bus, Event Grid, or another supported Function trigger; define checkpoint/replay, timeout, scale/concurrency, downstream throttling, poison handling, and telemetry. Where supported, a managed identity plus a Dataverse application user/security role avoids a stored client secret. Prove the effective identity and permission rather than assuming assignment alone completes authorization.

For cloud flows:

choose the Dataverse trigger and set change type, scope, table, select columns, filter rows, and trigger conditions to avoid noisy runs;
use expressions with explicit null/type/time-zone handling and name steps/variables for maintainability;
mark sensitive inputs/outputs and prevent secrets from entering run history; retrieve secrets through an approved Key Vault connection;
use scopes, Configure run after, retry policies, timeouts, Terminate, and a stable error/telemetry contract;
make external side effects idempotent and control concurrency when ordering or updates can conflict;
keep reusable child flows solution-aware with explicit inputs/outputs, connection references, ownership, and failure propagation;
use an Entra service principal/application user where an application identity is required, with least privilege and a supported connector pattern.

Secure-input/output flags reduce exposure in run history but do not fix overprivileged connections or unsafe downstream logs. A retry without idempotency can duplicate an invoice, email, or external record.

Related item: AI agents and coding assistants can help draft Power Fx, JavaScript, C#, tests, and troubleshooting hypotheses, as the 2026 audience profile notes. Do not send tenant secrets or regulated data to an unapproved tool; review generated code, dependencies, permissions, sources, failure behavior, and tests exactly as human-written code.

6. Develop integrations¶

Publish and consume Dataverse events¶

Register a webhook, Azure Service Bus endpoint, or Azure Event Hubs endpoint against the required Dataverse message/stage, or publish through IServiceEndpointNotificationService from plug-in code. Understand whether publication occurs inside the originating transaction, what failure can do to that transaction, and what remote execution context the receiver gets.

Destination	Strong fit	Design proof
Webhook	Direct HTTPS notification to a service with simple request/response handling	Authentication, timeout, availability, retry/duplicate response, and endpoint rotation
Azure Service Bus	Durable enterprise messaging, queues/topics, competing consumers, dead lettering	Settlement, retry, duplicate detection/idempotency, ordering/session, DLQ replay
Azure Event Hubs	High-throughput event stream for multiple analytical/stream consumers	Partition key/order, checkpoint, retention, consumer groups, replay and schema evolution

Recommend a listener from delivery semantics, throughput, fan-out, latency, durability, replay, ordering, operations, security, and cost—not because all three can receive an event. The consumer should validate schema, authenticate source, deduplicate, trace correlation, handle poison data, and expose lag/failure/replay evidence.

Synchronize Dataverse data¶

Change tracking lets a client request changes since a prior token rather than repeatedly scanning the whole table. Persist the continuation/delta token only after durable processing, handle deletes/tombstones as documented, paginate until complete, and know how to perform a controlled full resynchronization when the token becomes invalid or the schema/retention contract changes.

Worked example — An expired delta token needs reconciliation¶

A replica contains records A, B and C. During an outage, B is deleted and D is created. A new full synchronization returns A, C and D; merely upserting those rows leaves obsolete B in the replica. Stage a complete replacement snapshot or reconcile the authoritative scope before advancing the new checkpoint. Incomplete pages or changed access scope are not sufficient evidence to delete missing replica rows.

The change-tracking documentation states that a token-free initial request returns current records without historical deletions. The default change-retention window is seven days, configurable through ExpireChangeTrackingInDays; RetrieveEntityChanges requires organization-level read access. With Web API tracking enabled, $filter, $orderby, $expand and $top are unsupported. Preserve returned continuation/delta URLs rather than reconstructing a filtered feed.

Alternate keys identify a Dataverse row by a stable external/natural key when the Dataverse GUID is not known. Choose a unique, immutable, normalized key and account for supported types, nulls, index readiness, special characters, and source-system scope. A mutable display name is usually a poor synchronization key.

Upsert/UpsertRequest can create a missing row or update an existing row addressed by its alternate key. It reduces lookup-then-write races but does not by itself solve duplicate source events, stale overwrites, conflict policy, transactional grouping, or downstream side effects. Record source version/time, idempotency, ownership, conflict resolution, reconciliation totals, rejected rows, and replay strategy.

The Upsert documentation distinguishes standard and elastic tables. Elastic-table Upsert does not raise separate Create/Update events and can overwrite the record payload, so validation registered only on those messages is insufficient. For Web API requests, If-Match: * makes PATCH update-only; without it, the request can create a missing row. Neither that wildcard nor Upsert alone prevents a stale write: compare the expected record version when concurrency matters.

Related item: Event-driven notification and change tracking solve different problems. Events can provide low latency; change tracking plus periodic reconciliation can prove completeness after outage, subscription error, or consumer failure. Robust integrations often use both.

7. Implement the current published code and AI scope¶

This section develops the code and AI objectives on the current published PL-400 outline. AB-400 registration and any existing PL-400 appointment remain separate; a course title alone does not establish complete coverage of either delivery. The September Power Platform update helps discover changed developer documentation. Verify each feature in its product page: an overall GA announcement does not make every associated integration GA.

Choose the experience and the execution contract¶

Keep invariant validation deterministic in a server operation. An agent can propose an action or resolve ambiguous intent, but validate identifiers, authorization and input before committing it. Choose a code app for a full custom web experience; a PCF control for an embedded field/data-set experience; client script/web resources for supported model-driven behavior; a generative page for an AI-authored page; and an interactive agent or MCP app widget for the supported conversational host. Document each host’s data, accessibility, deployment and lifecycle contract. Choose Copilot Studio for its managed authoring/connectors and Foundry when the application needs a code-owned agent/runtime design; test the actual integration route.

Worked example — generative reuse and flow¶

Define an order-review generative page's reusable input/output contract: record ID and allowed view in, selected order and proposed action out. Record data bindings, accessible states, solution dependencies and upgrade tests. Generated React remains reviewed application code; do not imply it is a canvas component-library item. Custom APIs retain signed-in-user security and current connector/custom-API/Application-Insights capabilities have preview boundaries. Compare Power Automate cloud flow and Copilot Studio standard-harness agent flow using trigger, typed input/output, connection identity, error/retry/idempotency and solution lifecycle. Agent-flow actions can call prompts or agents; deterministic flow structure does not make generated text deterministic.

Question: Where must exact maximum approved discount be enforced?

Answer: In an authorized deterministic server operation; page displays, agent proposes and workflow routes validation/approval.

Primary reference 1 · Primary reference 2

Build and promote a code app¶

Start with the code-app overview and development map. Verify environment enablement and end-user Power Apps Premium licensing. Compiled app assets are publicly served: never bundle secrets. Current limitations include no Secure Implicit Connections and no Power Platform Git integration; conventional source control for your project still matters.

Task	Implementation and verification
Connections and Dataverse data	Add the table/connector data source; inspect generated TypeScript models/services, query projection, paging and error handling. Use Dataverse integration guidance for CRUD, table metadata and lookup handling; distinguish record writes from schema operations. File/image support has its own preview boundary.
Actions and functions	Discover and generate operation bindings from environment metadata. Review bound versus unbound parameters, expected result and privilege; regenerate after contract changes.
Cloud flows	The code-app flow integration supports solution-aware instant flows with a Power Apps trigger. An arbitrary scheduled or automated flow is not interchangeable. Verify connection identity, inputs, response and failure.
Copilot Studio	Use a published agent and the supported code-app connector route. Trace connection identity and the returned response; do not infer delivery behavior from an action name containing `Async`.
Environment configuration	Use solution variable schema references such as `@envvar:` for supported data-source fields, then verify target values in the environment-variable workflow. CLI process variables configure the tool and are a different mechanism.
Deployment and sharing	Follow code-app ALM, select the intended solution and retain the built artifact. For service-principal publishing, the maker must first grant the principal edit access to the existing app; environment access alone is insufficient. Use the Enterprise Application object ID for that share.
Monitoring and performance	Configure Application Insights as appropriate, correlate requests, redact sensitive telemetry, and use Monitor/browser traces to separate rendering, network, connector, authorization and server failures. Measure query/page sizes, repeated requests, bundle size and resource cleanup under the least-privileged persona.

Build code apps against explicit data contracts¶

Confirmed — VERIFY CURRENT (October 28, 2026). A code app uses a web framework and the Power Apps client library; it is a complete app experience rather than a PCF control embedded in an existing host. Adding a Dataverse data source generates TypeScript models and services. Inspect table metadata and generated types, select only needed columns, page deliberately, and send only changed fields on update. Current client limitations include metadata CRUD, FetchXML, alternate keys and polymorphic lookups; capabilities in another Dataverse SDK do not prove support here.

For Dataverse actions/functions, current instructions require @microsoft/power-apps 1.1.1+ and use pa app find-dataverse-api then pa app add dataverse-api. Discovery produces schemas and a generated service; it does not grant operation privileges. A bound operation also needs the target record ID. Regenerate after a contract change and inspect the diff before deploying.

Proposed practice extension — not executed: Use a synthetic account table, a read-only WhoAmI function and one approved custom action. Record generated files, selected columns, paging, caller identity, denied operation and stale-schema behavior. Keep unsupported metadata mutation in a separate SDK exercise.

Answer checkpoint: Why can schema discovery succeed while an action fails? Discovery, binding, authorization and execution are separate checks.

Move configuration and code together¶

Use solution environment variables for supported dataset/table values. The current CLI accepts @envvar:<schema-name> references and retains them in power.config.json; resolve the target environment's values during promotion rather than copying development URLs. A connection still needs to exist and be authorized. Do not confuse solution configuration with process variables that configure the CLI.

Current code-app ALM uses pa app push. An explicit solution target is a GUID; without Dataverse, the app can publish without a solution. A subsequent push without a solution ID does not move existing solution membership. Choose the solution deliberately, use supported pipelines for promotion, and retain conventional source control because built-in source-code integration is currently unsupported. VERIFY CURRENT: CLI names, source integration and deployment behavior.

Proposed practice extension — not executed: Compare development and test data-source references, connection bindings, solution membership, dependencies, sharing and actual restricted-user access. Prove the test app uses test data after import; successful upload alone is insufficient.

Diagnose the browser and telemetry boundaries¶

Confirmed — VERIFY CURRENT (October 28, 2026). Code-app CSP applies at environment scope. Its current default connect-src is 'none'; only permit required endpoints and pilot changes with reporting. A custom source normally augments a directive, whereas a 'none' default is replaced. Updating the complete directive collection can replace earlier settings; retrieve and review it before writing. An empty source array disables that directive instead of meaning deny-all.

Application Insights integration captures session/network metrics only after the app loads. Startup or blocked-file failures require Power Platform Monitor and browser evidence. Configure the logger once, check required CSP endpoints and exclude sensitive payloads. The telemetry article's environment-variable limitation concerns instrumentation configuration; the supported data-source environment-variable route above does not establish a general runtime settings API.

Proposed practice extension — not executed: Tabletop a blocked startup asset versus a loaded app whose telemetry endpoint is blocked. Identify which tool can observe each failure, expected evidence and the narrow CSP change. Compare selected columns, repeated requests and timings under the affected user's role.

Answer checkpoint: Does an empty App Insights dashboard prove nobody opened the app? No; startup or telemetry transport could have failed.

Worked example — choose an alert that can meet the response time¶

Design a supported resource alert in a managed test environment: product/type, environment/resource scope, metric, operator, justified threshold, severity, owned recipients and linked runbook. Correlate triggered resource with flow runs or Application Insights request IDs. The current overview and FAQ describe 24-hour aggregates and daily evaluation; creation performs on-demand evaluation. Resource-scoped code-app rules also offer a preview Data review period of 24 hours or 1 hour; the latter enables hourly metric aggregation. Record the selected period, Last Run and delivery evidence: an hourly data window alone does not establish an hourly alert-delivery SLA. Treat rule state, email delivery and incident response as separate evidence. Use an appropriate faster telemetry detector for real-time exception response.

For a disposable StudyReview code app, choose a currently supported start-screen load metric, convert a justified five-second business target into its displayed units, assign an owning operations team and link its startup-failure runbook. Record environment/resource IDs and the supported aggregation. This is a planning card, not a deployed alert or a guarantee that a one-minute incident will trigger the selected metric rule.

Question: An exception happened one minute ago and no Monitor alert fired. Is the rule broken?

Answer: Not established. Check aggregation/evaluation schedule, metric, scope, threshold and notification; this detector may be too slow for the SLO.

Primary reference 1

Worked example — An empty CSP source list is not a deny-all rule¶

An administrator turns off a code-app CSP directive’s default toggle and leaves its custom source list empty. The documented UI behavior omits that directive; it does not produce a deny-all directive. The browser then uses any applicable fallback directive, which may allow more than intended. Distinguish reporting from enforcement, inspect the response policy, and test an allowed and disallowed resource. The code-app CSP guide also warns that its API helper replaces the entire directive collection: retrieve and preserve other settings before changing one.

Extend APIs without losing execution limits¶

The Dataverse SDK for Python supports data/metadata operations, paging and retries using Azure identity credentials. Compare operation semantics and table type with .NET/Web API, pin the library, and inspect retry behavior before layering another retry loop. A bulk method does not make every operation universally atomic.

Background operations remain preview and run requests implemented as custom APIs asynchronously. The plug-in’s two-minute timeout still applies. Track the returned operation/status resource, distinguish accepted from completed, and make retries safe. Canceling after execution starts does not stop that running operation. Use external workload processing when work exceeds the plug-in execution contract.

Use the Dataverse SDK for Python deliberately¶

The Python SDK supports Azure Identity-compatible credentials, CRUD, paging, bulk operations and table/column metadata operations. Its simple SQL query surface is read-only SELECT, not a general SQL write channel. Distinguish multiple native bulk operations from a batch containing an explicitly transactional changeset; do not infer one universal all-or-nothing guarantee. Record package version, effective identity, table support, retry behavior and per-operation results. VERIFY CURRENT: supported operations and library contracts.

Proposed practice extension — not executed: Build a small synthetic read/update operation using least privilege; inspect paging, one rejected record, response shape and safe retries. Compare metadata operations with the separate code-app client's unsupported metadata-CRUD boundary.

Background processing changes connection lifetime¶

Confirmed — VERIFY CURRENT; preview (October 28, 2026). Dataverse background operations execute a custom API asynchronously, allowing the client connection to return. They retain the two-minute plug-in execution limit. The caller needs read/write privileges on the background-operations table. A Web API request using Prefer: respond-async returns an operation ID and status URL; that status resource differs from the OData table URL.

Poll conservatively or use the supported completion notification. A cancel request prevents work that has not started; it does not interrupt an already running operation. The documented retry policy can replay failures, so external effects still require idempotency. Select an external worker/Azure Function when execution itself exceeds the platform limit.

Proposed practice extension — not executed: Model queued, running and completed cancel requests and a transient failure after an external effect. State which work can continue, which identifiers correlate it and how duplicate effects are prevented.

Answer checkpoint: Does respond-async make a five-minute synchronous custom API valid? No; it releases the client connection without extending plug-in execution time.

Worked example — compare the same operation across two SDKs¶

Implement the same bounded operation contract using .NET and Python adapters: authenticate least-privileged app; read known account's ID/name/version; retrieve a filtered page and follow continuation; attempt update under reader identity and expect denial. Record exact SDK version, audience, principal, projection, result version and error category. Compare empty pages,403,429/Retry-After and stale-version handling. Use installed-version documented methods; do not invent Python methods by analogy with Organization service. Account for each SDK's own retries before adding an outer loop; bulk method does not guarantee universal atomicity.

For example, account study-A has name Contoso Study and version v8. Both adapters must return that identity/version, preserve a continuation token and expose a denied update under the reader persona. An updater using expected v7 must not silently overwrite v8. A successful .NET path does not establish the Python SDK method signature, retry policy or transaction behavior; select the installed-version documentation for each adapter. This is an operation-level implementation exercise, not invented executable SDK code.

Question: Automatic SDK retries make blind outer retries safe?

Answer: No. Classify failure, bound total attempts/time and make uncertain writes idempotent or reconcile them.

Primary reference 1

Connect agents through the correct protocol and identity¶

Dataverse MCP exposes data and schema tools; configure the environment and allowed clients, then test read and mutation privileges separately. Tool discovery is not permission to perform every action. A custom MCP server also needs explicit tool schemas, authentication, authorization, error handling and a controlled mutation contract.

The Copilot Studio client library, available for .NET, JavaScript and Python, connects custom agents/apps to Studio agents. Current guidance supports the standard harness, not agents using the GitHub Copilot harness. This client-library route and the code-app connector route have separate contracts.

For Dataverse business context, Business Applications in Work IQ is preview. Copilot audience, Work IQ MCP availability and environment App Access controls are separate; participation settings alone do not block agentic data access. Foundry’s Work IQ integration currently uses A2A and delegated user/OBO authentication. Do not assume every Work IQ route is MCP or supports app-only authentication. Record the exact provider, protocol, user/application identity, privileges and data boundary in the design.

Choose the supported agent client¶

For a code app, the Copilot Studio connector procedure creates/selects a connection, adds it as a data source, generates a service and calls a published agent by its exact name. ExecuteCopilotAsyncV2 waits for responses despite its name; the older ExecuteCopilot returns a conversation ID without the answer. Inspect completion and response fields rather than equating receipt of an ID with task success.

For a custom web/native application or another code-first agent, the Copilot Studio client library has .NET, JavaScript and Python samples. Current support is for the standard harness, not the GitHub Copilot harness. VERIFY CURRENT: connector actions, client/harness support and generated contracts.

Proposed practice extension — not executed: Compare a code-app connector call with a standard-harness SDK client as two integration paths. Record publication, environment, connection/identity, agent name, response completion and failure evidence; test a nonexistent name without weakening authentication.

Integrate custom agents through governed tools¶

A code-first Foundry agent needs a model, instructions and explicit tool configuration, plus an application-level loop that handles tool output, errors and approval. Choose shared workload access only when every caller should receive the same data scope. Foundry MCP authentication distinguishes shared credentials/identities, incoming-user delegation and per-user OAuth consent; one method's support does not establish another's. Treat project connection creation, OAuth consent and approval of a proposed tool call as separate states.

The developer MCP guide also separates consuming a governed server, building one from connectors/Dataverse custom APIs, and registering a BYO server for administrative review. For consumption, inspect the allow-listed tools and invoke the smallest authorized operation. Registration alone does not prove tenant consent, supported client routing, Dataverse authorization or successful invocation. VERIFY CURRENT: endpoint, host, identity, scope, preview and rollout support.

Proposed practice extension — not executed: Use a read-only table query plus a simulated write proposal. Record exact server/client, tools/list schema, effective identity, source/table permission, approval and trace IDs. Reject an unauthorized table or tool; use tabletop evidence when the client path is unsupported.

Answer checkpoint: Why can successful MCP sign-in still produce a denied Dataverse call? Server/client approval, scope and underlying Dataverse permissions remain independent.

Distinguish the Work IQ integration surfaces¶

Confirmed — VERIFY CURRENT; preview (October 28, 2026). Business Applications in Work IQ uses tenant, environment and app controls. Current defaults exclude nonproduction environments and have regional/government exceptions; do not assume a developer environment matches a production rollout. A table shared through another enabled app can remain available after one app is disabled.

This business-app integration does not establish support through every Work IQ tool. The current generic MCP retrieve reference explicitly excludes Dataverse and Power BI, even though a Dataverse capability name appears in the schema. Treat that path as unavailable until the reference changes.

The separately documented Dataverse Ask APIs accept natural-language questions against a semantic model and can return structured rows plus a summary. Their /api/iq/v1.0/ route is not the OData /api/data/ service and does not support OData options or dedicated .NET/Python SDK client classes. Use HTTP with the correct Dataverse token, and use the Web API for precise CRUD.

Proposed practice extension — not executed: Make a matrix for Business Applications settings, a model-scoped Ask request, generic Work IQ retrieve and exact Web API CRUD. Record each endpoint, supported inputs, identity, data scope and availability. A generated schema name is not a successful integration test.

Answer checkpoint: Does a Dataverse enum in the generic retrieve schema prove support? No; current explicit source limitations control the design.

Worked example — a proposed update is not a committed update¶

Design an ORIGINAL custom-server tool propose_case_update: require caseId, expectedVersion and proposedStatus; reject extra fields; return proposalId, currentVersion, validationErrors, requiresApproval. These teaching names are not built-in Dataverse tool names or provider wire syntax. Bind authenticated tenant/caller server-side. A read-only caller's mutation is denied without writing; stale expectedVersion produces conflict. A separate idempotent commit validates approval and current state. For custom-agent to published Studio-agent handoff, carry bounded question, approved facts, correlation/conversation IDs, timeout and structured proposal validation. Confirm standard harness, tenant/environment, audience and caller grants. Do not translate that logical message directly into undocumented SDK calls.

The JSON below is an original logical contract, not a provider endpoint or complete MCP wire message.

{
  "tool_name": "propose_case_update",
  "input_schema": {
    "type": "object",
    "properties": {
      "caseId": {
        "type": "string"
      },
      "expectedVersion": {
        "type": "string"
      },
      "proposedStatus": {
        "type": "string",
        "enum": [
          "InProgress",
          "Resolved"
        ]
      }
    },
    "required": [
      "caseId",
      "expectedVersion",
      "proposedStatus"
    ],
    "additionalProperties": false
  },
  "expected_result": {
    "proposalId": "study-proposal-7",
    "currentVersion": "v8",
    "validationErrors": [],
    "requiresApproval": true
  }
}

Question: Does discovery of update_record authorize every caller to change every case?

Answer: No. Downstream authorization, current-state validation and approval remain separate. Current Dataverse MCP search_data searches data, search searches metadata, and describe replaces old discovery tools.

Primary reference 1 · Primary reference 2

Integrated scenarios¶

Scenario 1 — Regulated case-management extension¶

A model-driven app needs an accessible custom control, a command that launches a custom page, and a server-enforced approval rule. Use supported Client API/commanding and a packaged PCF component for the experience; put the invariant in a short PreOperation plug-in or named custom API; run follow-up notification asynchronously. Package roles, components, connection references, configuration, and tests in a solution. Prove unauthorized API and import callers cannot bypass the rule, and redact case data from traces.

Scenario 2 — Partner service connector¶

A canvas app must invoke a partner REST API with OAuth, then process work that can outlast the interactive request. Publish a versioned OpenAPI custom connector with least-privilege OAuth and a stable error schema. Return a tracking ID, enqueue/trigger a Function for long work, and make status/result retrieval idempotent. Apply DLP, bind each environment through solution configuration, respect partner throttling, and correlate app, connector, Function, and partner logs.

Scenario 3 — Resilient customer synchronization¶

An external master sends frequent customer changes and requires nightly completeness evidence. Use a stable external ID as an alternate key and Upsert with source-version conflict rules. Publish low-latency Dataverse events through Service Bus for downstream work, checkpoint the consumer, dead-letter poison messages, and run change-tracking reconciliation to find gaps. Exercise duplicate, delayed, reordered, deleted, throttled, and full-resync cases before release.

Hands-on labs¶

Lab 1 — Architecture and security decision¶

Given one validation, one orchestration, and one external-data requirement, compare out-of-box, client, plug-in, flow, connector, Function, and table choices. Evidence: component/trust-boundary diagram, identity/role/DLP matrix, decision record, limits, and failure plan.

Lab 2 — Solutions and automated promotion¶

Create developer/test environments, an unmanaged solution, environment variable, connection reference, and least-privilege role. Export/unpack/build/check/import through a pipeline. Evidence: reviewed source diff, immutable artifact, deployment settings without secrets, test results, layer/dependency inspection, and recovery drill.

Lab 3 — Advanced canvas app¶

Build complex Power Fx with explicit errors, a reusable library component, and a flow call. Introduce a delegation issue and repeated network calls, then use Monitor to repair them. Evidence: full-set correctness, before/after traces, caller/connection identity, timeout/error behavior, and accessibility check.

Lab 4 — Client script and commands¶

Register form event handlers using execution context, call Web API asynchronously, add Power Fx and JavaScript commands, and navigate to a custom page. Evidence: supported-API inventory, permission/error tests, unsaved-record behavior, browser trace, and solution contents.

Lab 5 — PCF component¶

Create a manifest and TypeScript control implementing lifecycle, bound output, resize, disabled/loading/error states, accessibility, and one supported feature. Package/deploy/consume it. Evidence: unit/harness/host tests, dependency scan, performance trace, and upgrade/removal test.

Lab 6 — Plug-in and custom API¶

Implement validation/mutation with appropriate pipeline stages, filtered attributes, images, tracing, and a named custom API. Test user/application identities and deliberate failures. Evidence: registration export, transaction/rollback results, recursion/performance tests, and least-privilege proof.

Lab 7 — Connector, Function, API, and flow reliability¶

Create an authenticated OpenAPI connector backed by a Function; build a solution-aware parent/child flow using Key Vault and secure I/O. Inject 401, 403, 409, 429, timeout, and duplicate delivery. Evidence: bounded retry/idempotency behavior, redacted correlated telemetry, DLP result, and environment promotion.

Lab 8 — Events and synchronization¶

Register a Service Bus or webhook endpoint, consume remote context, dead-letter one poison event, then synchronize with change tracking, alternate keys, and Upsert. Evidence: checkpoint/token state, duplicate/reorder/delete tests, DLQ replay, row/field reconciliation, and controlled full resync.

Lab 9 — Failure boundaries and reconciliation¶

Model the unchanged filtering attribute, a successful external notification followed by Dataverse rollback, an expired change token and elastic-table Upsert. Test with synthetic records where a tenant is available; otherwise produce a predicted event/transaction matrix. Evidence: included versus changed attributes, actual committed state, duplicate side effects, complete replica membership and current token policy.

Lab 10 — Replacement-scope code app and agent pilot¶

In a disposable environment or tabletop, design a code app with Dataverse data, a bound action, supported flow, published Studio agent, target environment variables and explicit solution membership. Compare CSP report/enforce behavior and service-principal environment/app permissions. Trace an MCP mutation and a delegated Work IQ request with a denied persona. Evidence: artifact/version, host and preview prerequisites, actual execution identity, allow/deny results, correlation and cleanup. Mark unavailable capabilities as not executed.

Knowledge checks¶

First extension question? Can supported out-of-box configuration meet the requirement and its operating constraints?
Client rule versus plug-in? Client logic improves one UI; a plug-in can enforce a server rule across clients and APIs.
Virtual table versus connector? Dataverse-shaped access to external data versus invoking external operations/data from an app or flow.
Elastic table decision? Prove its scale fit and feature/consistency/query/security limitations against the requirement.
Authentication versus authorization? Proving caller identity versus deciding that caller's allowed operations/data.
What does DLP control? Which connector data groups may be combined; it does not grant source or row access.
Why threat-model the design? To attach controls/tests to trust boundaries, privileged operations, secrets, data, and failures.
Why developer environments? Isolation and reproducibility before governed promotion, without direct production customization.
Unmanaged versus managed solution? Editable development source container versus controlled downstream deployment layer.
Environment variable purpose? Nonsecret configuration that changes by environment without changing component logic.
Connection reference purpose? Solution-aware binding between a component and an environment's connector connection.
Why inspect solution layers? To identify which managed/unmanaged layer currently determines behavior.
What belongs in source control? Unpacked solution metadata, conventional code, OpenAPI/configuration templates, tests, and build instructions—not secrets.
Delegation risk? A nondelegable formula can calculate only a local subset and return an incomplete answer.
Why not preload everything? Startup, memory, staleness, network, and delegation costs can outweigh later savings.
Monitor versus browser tools? App/platform events and formulas versus browser console/network/client behavior; use both where needed.
Canvas component library value? Versioned reuse across apps through explicit properties and consumer upgrades.
Why is client validation insufficient security? Other clients and direct APIs can bypass browser/app logic.
Modern command Power Fx versus JavaScript? Declarative supported command logic versus richer supported Client API behavior.
PCF lifecycle? Initialize, react/render on context changes, return outputs, then release resources.
Manifest purpose? Declare identity, component type, properties/data sets, resources, and required platform features.
PreValidation fit? Reject invalid work early, usually before the main transaction; understand nested-operation context.
PreOperation fit? Mutate/validate inside the transaction before the core operation.
PostOperation async fit? Eventual post-commit work that should not delay or roll back the user transaction.
Why filtering attributes? Avoid irrelevant Update executions; they do not prove the value actually changed.
Pre/post images? Registered snapshots of selected row values before/after supported pipeline operations.
Custom API action versus function? A state-changing command versus a side-effect-free operation.
Why version connector contracts? Consumers depend on schemas, authentication, errors, and behavior independently of implementation.
Correct response to 429? Respect Retry-After, bound retries, make replay safe, and tune concurrency from telemetry.
Managed identity completes Dataverse access? No; map/authorize the identity as an application user with a least-privilege role.
Secure flow I/O solves what? Run-history exposure; it does not fix broad permissions or downstream logging.
Why use child flows? Reuse solution-aware orchestration with explicit inputs, outputs, connections, ownership, and failure semantics.
Webhook versus Service Bus? Direct HTTP notification versus durable messaging features such as queue/topic and dead lettering.
Change-tracking token rule? Persist advancement only after durable processing and retain a controlled full-resync path.
Alternate-key requirement? Stable, unique, normalized external identity—not a mutable display label.
What does Upsert not solve? Duplicate events, stale conflicts, side effects, ordering, reconciliation, or transaction design.
Does supplying the same filtered attribute value skip an Update plug-in? No; presence can trigger the step. Compare the image and target for a real change.
Can Dataverse rollback undo a completed external HTTP side effect? No; design post-commit delivery, idempotency and reconciliation.
Does a fresh full sync contain all historical deletes? No; reconcile the complete authoritative scope so obsolete replica records do not remain.
Does elastic Upsert necessarily trigger Create/Update plug-ins? No; include required validation in the Upsert path.
Can a personal platform-host pipeline be extended for approvals? Not through personal-pipeline extensions; evaluate a custom host design.
Do asynchronous background operations allow a ten-minute plug-in? No; the plug-in timeout remains two minutes.
Does environment access let a service principal update any code app? No; the existing app also requires maker-granted edit access.
Does disabling a CSP directive with an empty list deny all sources? No; it omits that directive. Inspect fallback policy and test actual enforcement.

Final readiness checklist¶

I can justify out-of-box, Power Fx/business rule, client script, plug-in/custom API, flow, connector, Function, or event processing from requirements.
I can choose standard, virtual, or elastic tables and explain identity, security-role, DLP, data, transaction, and failure boundaries.
I can package dependencies, environment variables, connection references, roles, code, and PCF into solutions and promote them through a tested pipeline.
I can implement and diagnose advanced canvas/model-driven logic without delegation, performance, permission, or client-only-security mistakes.
I can implement supported Client API/command/custom-page behavior and a packaged, accessible PCF component through its complete lifecycle.
I can register efficient plug-ins, images, custom APIs, connectors, Web API/SDK clients, Functions, and flows with bounded retry and correlated telemetry.
I can choose webhook, Service Bus, or Event Hubs and build an idempotent consumer with checkpoint, dead-letter, replay, and reconciliation behavior.
I can synchronize with change tracking, alternate keys, and Upsert while handling deletes, conflicts, duplicates, invalid tokens, and full resynchronization.
For AB-400, I can explain the code-app, background-operation, Python SDK and agent integration additions and verify the exact route, permissions and preview status.
I have rechecked the October registration/delivery dates and the applicable blueprint before scheduling.

Places to learn¶

October 28 learning route and evidence task¶

The official PL-400 course still lists five days. The Pluralsight path publishes nine courses/about 15 hours, with 2022–2023 dates. Its body also calls PL-400 “App Maker”; use the official blueprint for credential identity and scope. This path can offer durable code/extension explanations, but the date and inconsistent label make a current gap map essential. Keep the existing official lab repository as selective practice; the AB-400 successor-training note already supplies the transition route.

Original extension-review exercise (about 30–45 minutes, editorial estimate): Take one older lesson’s plug-in, connector or event scenario and create an implementation decision card: objective, client/server trust boundary, execution identity, transaction boundary, retry/duplicate risk, 2026 documentation and independent test. Classify the Dataverse Skills blog’s generated mutations by these same fields before accepting them.

Answer checkpoint: An AI tool selecting the correct API does not prove the caller has permission, the mutation belongs in the right solution, or an external side effect rolls back with Dataverse.

October 28 learning-resource check¶

Additional options and access updates; choose relevant resources rather than consuming every route. New course availability, class delivery and licensing are VERIFY CURRENT. Published days describe instructor-led scope, not measured self-study time.

Resource	Access	Estimated time
AB-400T00 successor training	Public outline; class/provider access may be paid	3 published days; adjacent AB-400 preparation after PL-400T00 courseware retirement on October 30; not proof of identical exam coverage

This is a curated starting point, not a complete list, and it is not meant to be consumed in full. Choose one current primary path, implement the ten labs or equivalent work, and use other resources only to close measured gaps. Reconcile every resource with the current October 16 published outline and the appointment code; older courses can still teach fundamentals but may use prior weights, deprecated tooling, or objectives that have moved.

The nine self-paced paths recorded during the September 1 review cover advanced canvas apps, expressions/Dataverse flows, developer foundations, client scripting/commands, PCF, Dataverse extension, Azure integration, custom connectors, and ALM. Their recorded durations totaled about 25 hours; the September 27 public course shell reconfirms five days of instructor-led delivery but does not independently reverify that path-duration sum. Allow 50–90 hours with coding, tenant setup, failure testing, and notes.

Resource	Access	Estimated time
Official PL-400 blueprint and credential page	Public	1–2 hours initially; 15 minutes per recheck
Nine self-paced paths from PL-400T00	Public	About 25 hours recorded September 1; allow 50–90 hours with exercises and independent builds
PL-400T00 instructor-led course	Paid/partner delivery	5 days listed
Official MicrosoftLearning PL-400 labs (MIT)	Public	About 15–30 hours selectively; repeat key labs without instructions
Microsoft PL-400 Practice Assessment	Public	45–75 minutes per attempt plus source-based remediation
Microsoft Exam Readiness Zone PL-400 series	Public	About 2.5–3.5 hours for six 2024 episodes; useful foundation, but reconcile old weights with 2026
Pluralsight PL-400 path	Paid	15 hours / 9 courses plus practice exam; courses date from 2022–2023, so use for foundations and supplement 2026 changes
O'Reilly/Pearson PL-400 Developer Crash Course	Paid	About 6 hours across the published two-day agenda; older scope includes retired/moved objectives, so use selectively
Udemy PL-400 prep by Phillip Burton	Paid	13h56 / 135 lectures; updated March 2026 and explicitly states March 19 alignment
Whizlabs PL-400	Paid	Public page did not expose dependable current totals; allow 8–20 hours selectively and verify 2026 alignment before purchase
MeasureUp PL-400 practice test	Paid	103 questions; last updated August 2024, so use for older foundations and map every miss/source to the 2026 blueprint
Microsoft Power Platform YouTube	Public	3–12 hours selectively for current platform/developer sessions; not an exam checklist
Partner Skilling Hub / ESI PL-400 delivery	Partner-restricted	5-day course pattern; verify the signed-in event's exact published start/end time

Use assessments to find weak objectives, then return to first-party documentation and your own environment. Reject recalled live questions, “actual exam” files, guaranteed-pass material, and repositories that reproduce protected exam content.

Qualified blog reading — Review the agent’s proposed platform changes¶

Dataverse Skills: Your Coding Agent Now Speaks Dataverse, Suyash Kshirsagar, April 1, 2026. Allow 10–15 minutes plus an original exercise: draft a synthetic two-table recruiting model, then review the proposed environment, relationships, security, solution membership and sample-data mutations before allowing a coding agent to execute it.

The article is useful for understanding tool selection and orchestration. Reconcile its frictionless setup claims with the current plugin documentation: the feature is preview, the caller needs suitable privileges, and MCP consent/client allowlisting are still required. The public article was read; its video, plugin installation and tenant demonstration were not executed.