Introduction

A sound Microsoft Power Platform extension design can show where a business rule is enforced, which identity crosses each boundary, what succeeds or rolls back together, and how a caller discovers the final outcome. This Extension Design and Reliability Review Checklist turns those distinctions into observable checks. Accept a check only when the design has a stated contract and supporting evidence; stop when a failed or missing check could permit unauthorized access, inconsistent state or an unobservable business outcome.

Use the checklist after learning the foundations. It is a decision framework for reviewing an existing design or revisiting weak distinctions, rather than an implementation procedure. A working demonstration establishes one path through a system; the review also needs evidence from denied access, repeated requests, dependency failures and the deployed destination.

Prepare the Review Evidence

The prerequisite reading is AB-400: Choosing Power Platform Extension Architectures, AB-400: Designing Security and Dataverse Data Boundaries, AB-400: Custom APIs, Business Events and Plug-in Identity, AB-400: Reliable Dataverse Bulk and Background Operations, and AB-400: Dataverse MCP and Work IQ Access for Agents. Return to the relevant foundation when a distinction is unclear instead of memorizing an isolated component name.

Prepare one small evidence record per check: the requirement, selected boundary, expected observation, actual observation or missing evidence, and owner of any correction. Mark a proposed test as pending until someone executes it. Use an approved isolated environment, synthetic records and deliberately limited identities for failure tests. Agree resource costs and cleanup before creating paid resources or temporary access.

This review uses the AB-400 skills scope effective October 16, 2026, selected and verified on October 15. Product references were reopened on October 16 without changing that baseline. The criteria below are editorial engineering recommendations, not Microsoft's exam questions or an official release-approval standard.

Extension Design and Reliability Review Checklist

1. Place Enforcement Separately from User Interaction

  •  Identify each rule that must hold across every client. Show the server-side enforcement point and a direct service request that cannot bypass it. A disabled button or a generated interface is insufficient evidence for such a rule.
  • Name the actual user-experience host. A generative page belongs to a model-driven app; a Model Context Protocol (MCP) app widget renders in Microsoft 365 Copilot; a Power Apps code app is a custom business web application. Demonstrate the selected host and its supported interaction, rather than accepting a screenshot from a different surface.
  • Separate AI-produced suggestions from decisions requiring repeatable enforcement. Agent flows provide a rule-based path, but they can contain AI actions; review the output contract of those actions instead of assuming every value is deterministic.

Pass when the host supports the required experience and every invariant has an enforcement point independent of presentation. Stop when a client or agent can submit a prohibited state directly, or when successful rendering is the only evidence offered for correctness. Generative-page connector and custom application programming interface (API) support are preview features in the selected documentation; the review must retain that qualification and validate generated code.

2. Trace Identity and Authorization in Both Directions

  •  Record the principal and required permission for each hop, including the identity used by a saved connection. Test one allowed operation and one operation outside that principal's intended scope.
  • Inspect effective Dataverse access across roles and team memberships. Privileges are cumulative: a narrower role does not cancel a broader grant. An administrative test account cannot prove the boundary of a restricted user.
  • Review outbound plug-in identity separately from inbound Dataverse access. Microsoft Power Platform managed identity uses the documented version 2 federation setup for plug-ins; token acquisition and permission at the target Azure resource need separate evidence.

Pass when the observed access matches the intended principal and data scope on each hop. Stop when the design relies on authentication alone, uses a broad account to conceal a denied operation, or treats an outbound managed identity configuration as proof that an external caller may access Dataverse. Keep tokens, secrets and sensitive record contents out of the evidence record.

3. Match the Data Model to the Required Guarantee

  •  State which system owns the authoritative record. A virtual table retrieves external state through a provider without replicating that data into Dataverse; demonstrate the required operation and the behavior when the provider is unavailable.
  • Check the specific table type against the required consistency, relationships and transaction behavior. Elastic tables offer scale-oriented capabilities, but do not support multi-record transactions. A familiar Dataverse API does not establish equivalence with standard tables.
  • For each required invariant, identify the records it spans and the behavior permitted after partial failure. Record a rejected alternative and the missing guarantee that rejected it.

Pass when the selected storage or access model supports the actual invariant and its failure behavior is explicit. Stop when a design promises atomic changes across elastic-table records or assumes a virtual table has become a local synchronized copy. An unavailable external source should remain distinguishable from a valid empty business result in the application's contract.

4. Review Component Lifecycle and Operation Contracts

  •  For a Power Apps component framework (PCF) control, examine repeated updates and removal, not just initial rendering. The framework calls updateView for property-bag changes and destroy for cleanup. Demonstrate that repeated updates do not multiply subscriptions or writes and that removal releases owned resources.
  • For a custom API, inspect request types, responses, caller permission and the meaning of success. A custom API can represent a business event without a main-operation plug-in; its successful invocation alone does not prove that business work ran.
  • Distinguish an API's discoverability from access control. The custom API IsPrivate setting does not prevent a knowledgeable caller from invoking it. Require the intended privilege and business validation evidence independently.

Pass when the host lifecycle and named operation's observable contract match the implementation. Stop when stale callbacks can mutate removed UI, a response promises work that no component performs, or privacy in metadata is being used as the authorization boundary.

5. Draw the Commit Boundary Before Testing Failure

  •  Mark which Dataverse steps execute inside the transaction. For standard-table pipeline reasoning, synchronous PostOperation can still roll back the transaction; asynchronous PostOperation runs outside it after the record operation completes.
  • Check nested execution rather than labeling every PreValidation step as outside a transaction. Subsequent operations can inherit the calling extension's transaction. Use execution context and registration evidence to support the claim.
  • Inject a controlled failure at a chosen boundary and inspect every intended write and external effect. State which effects must be absent, which may remain and which require repair. Do not apply standard-table rollback assumptions to elastic tables.

Pass when observed commit and rollback behavior matches the documented boundary. Stop when a later notification failure is expected to undo an already completed operation, or when an external side effect is assumed to participate in a Dataverse database transaction. Keep the failure test small and reversible; it should establish a guarantee without altering production records.

6. Distinguish Acceptance, Completion and Safe Retry

  •  Capture the asynchronous operation identifier and the supported way to observe a terminal result. Dataverse background operations are preview and execute custom API requests asynchronously; they do not extend the invoked plug-in's two-minute execution timeout.
  • Demonstrate a failed terminal result as well as successful completion. The application must not report completed business work merely because submission succeeded. Record who resolves operations whose outcome remains unknown.
  • For public Dataverse API clients, show that service-protection handling respects the returned Retry-After delay. Review bounded retry and concurrency behavior alongside duplicate prevention: waiting before retry does not make a business action safe to repeat.

Pass when a caller can distinguish submitted, completed, failed and unresolved work, and replay does not create an extra business effect. Stop when timeouts trigger blind resubmission, every error is retried, or asynchronous execution is proposed solely to evade a plug-in timeout. Use a stubbed or controlled failure to inspect retry behavior before conducting any authorized load testing.

7. Review Agent Tool Access Beyond Connection Success

  •  Record the actual enabled environment, allowed client and observed tool surface. Dataverse MCP access requires environment configuration; a tool list copied from an older example is not evidence of the current connection's capabilities.
  • Test an allowed data action and an out-of-scope action under the intended identity. Inspect both authorization failures and the agent's explanation of failure. A fluent response must not conceal an unsuccessful tool call.
  • Review the approval and validation path for consequential actions. Demonstrate that ambiguous or untrusted input cannot silently broaden the intended action, and that repeated orchestration does not repeat a completed business effect.

Pass when tool availability, effective permissions and business validation jointly constrain the action. Stop when connecting to an MCP server is treated as permission to use every table or tool, or when a widget's presence is confused with the underlying data-access boundary. Recheck tool names and policies when the documented tool surface changes.

8. Require Destination Evidence for Release and Recovery

  •  Associate the tested source version, solution components and destination configuration with one release candidate. Application lifecycle management (ALM) uses solutions to distribute components, with source control as the source of truth; an export file by itself does not show that dependent services are ready.
  • Review required dependencies, environment-specific configuration, connections and resource permissions in the destination. Repeat a permitted operation, a denied operation and a controlled dependency failure there.
  • Identify the correlation value and observation that let an operator distinguish submission from downstream completion. Name the recovery owner and the documented repair or replay action; include temporary-access and synthetic-data cleanup in the acceptance record.

Pass when the deployed candidate preserves the reviewed contracts and an operator can locate an unresolved outcome. Stop when import success substitutes for runtime acceptance, the destination still depends on a developer's connection, or recovery assumes that removing a solution reverses external business effects. Review destructive recovery separately before executing it.

Apply the Checklist to a Small Design Review

Consider an illustrative service-request design: an agent proposes a category, a server operation validates submission, and automation sends the request to an external dispatcher. These are proposed observations, not executed test results.

The review starts with three pieces of evidence. A restricted user can submit an allowed request but cannot change another team's request through the service boundary. A submission identifier lets the application show pending dispatch until an actual downstream result is recorded. Repeating the same business request after an ambiguous network failure does not create a second dispatch.

If the team can show only a successful chat response and a created Dataverse row, the authorization, completion and replay checks remain pending. If automation fails after the row commits, expecting the row to disappear is a design error; the record needs an explicit failure or unresolved state and a controlled recovery path. If the dispatcher permission is broadened merely to obtain a successful test, the identity check fails even when delivery works.

This is the practical value of the checklist: the same happy-path demonstration can coexist with several unresolved guarantees. Record each missing observation, assign its owner and return to the relevant foundation. Count neither component names recalled nor boxes ticked as evidence of reliability.

Common Review Mistakes and Closure

The most consequential review mistake is replacing a guarantee with a nearby success signal: UI validation for server enforcement, a token for authorization, a submission response for completion, or an imported solution for destination behavior. Each substitution leaves a different failure untested. Choose the smallest negative test that distinguishes the promised behavior from that misleading signal.

Close a check only against the reviewed candidate and its recorded scope. Reopen the affected checks when an identity, table type, execution mode, tool surface or deployment dependency changes. A missing observation remains pending; a contradictory observation requires correction and another observation after the fix.

Conclusion

Use the checklist to connect each design claim to observable evidence and a specific stop condition. The useful outcome is a review record that exposes uncertain boundaries and directs focused correction, with safe cleanup and recovery ownership. It supports post-learning judgment without claiming exam coverage or production readiness from recall alone.

Authoritative Sources