2.3 Recommending Extensibility Options
Key Takeaways
- Custom connectors wrap any REST API from an OpenAPI 2.0 (Swagger) definition or Postman collection, are reusable across apps, flows, and agents, and always require premium licensing
- Power Apps Component Framework (PCF) code components come in two types — field and dataset — and solve UI rendering gaps, never data integration problems
- Plug-ins are C# assemblies that run synchronously or asynchronously in the Dataverse event pipeline stages PreValidation, PreOperation, and PostOperation
- Webhooks deliver the Dataverse execution context as JSON to an HTTP endpoint with no assembly deployed to Dataverse, and Azure Functions are the typical receiving endpoint
- The exam's ranking rule is configuration before low-code and low-code before code — never recommend a plug-in where a business rule meets the requirement
Low-code covers most requirements, but AB-410 wants you to recognize the exact moment configuration runs out — and to pick the smallest extensibility step that closes the gap. The ranking rule is simple: configuration before low-code, low-code before code. Every step up that ladder adds build cost, test burden, and upgrade risk, and exam answers are graded against it.
Connector Tiers: Standard, Premium, Custom
Connectors are the platform's contract with external systems, and the exam tests the tiers precisely:
| Tier | What it includes | Licensing |
|---|---|---|
| Standard | SharePoint, OneDrive, Outlook, Teams, Excel, Planner | Included with Microsoft 365 seeded rights |
| Premium | Dataverse, SQL Server, Salesforce, ServiceNow, HTTP, and all custom connectors | Power Apps or Power Automate premium licensing |
| Custom | Your wrapper around any REST API | Always premium |
There are more than 1,000 built-in connectors. When none fits, a custom connector wraps a REST API: import an OpenAPI 2.0 (Swagger) definition or a Postman collection, configure authentication (OAuth 2.0, API key, basic, or Windows), and define actions plus triggers (polling or webhook-based). One custom connector is then reusable from canvas apps, cloud flows, and Copilot Studio agents — the exam loves this because a single API investment serves all three surfaces.
Power Apps Component Framework (PCF)
Power Apps Component Framework (PCF) is the answer when the limitation is the user interface, not the data. A code component is a TypeScript/HTML/CSS control — commonly built with React and Fluent UI — that you scaffold with the Power Platform CLI (pac pcf init), package into a solution, and deploy with full application lifecycle management (ALM). Two types matter for the exam:
- Field components replace the rendering of a single column: sliders, star ratings, maps, signature pads.
- Dataset components render a bound view: custom grids, calendars, galleries.
Code components run in canvas apps and model-driven apps. Reach for PCF only when no native control or configuration can produce the required experience — building a PCF control to render data a standard gallery could render is the classic over-engineering wrong answer.
Dataverse Server-Side Extensibility
When logic must run on the server, inside the transaction, Dataverse offers a ladder of its own:
- Business rules — no-code validation, defaulting, show/hide, and recommendations. At table (entity) scope they run server-side on every save, so they are always the first candidate.
- Plug-ins — compiled C# assemblies registered on Dataverse messages (Create, Update, Delete, or custom). They execute in the event pipeline at the PreValidation, PreOperation, or PostOperation stages, synchronously or asynchronously, in an isolated sandbox. Use plug-ins for transactional integrity: cascading calculations, validation that spans related rows, or external calls that need rollback semantics.
- Custom APIs — define a brand-new Dataverse message with typed input and output parameters, with or without a plug-in behind it, so makers and integrations call your operation like any native message.
The exam's favorite discrimination: 'must never be bypassed and must participate in the database transaction' points to a plug-in, while 'validation that functional consultants should maintain' points to a business rule.
Webhooks and Azure Functions
A webhook registers an HTTP endpoint against a Dataverse message; when the event fires, Dataverse POSTs the execution context as JSON to your URL — no assembly is deployed to Dataverse at all. The receiving endpoint is frequently an Azure Function: serverless code that scales per execution and bills per consumption. Azure Functions also back custom connectors when makers need the logic surfaced as a first-class action in apps, flows, or agents. Choose webhooks and Functions when the logic is heavy, long-running, owned by a central IT team, or shared beyond Power Platform; choose plug-ins when the logic must live inside the Dataverse transaction.
Custom Pages and Embedded Power BI
Two UI-facing options round out the toolkit. Custom pages bring canvas-style authoring into a model-driven app as a full page or dialog — the converged way to add one bespoke screen without abandoning the model-driven shell. Embedding Power BI covers analytics requirements: pin report tiles to model-driven dashboards, embed an interactive report filtered by the current row's context, or drop the Power BI tile control into a canvas app. If the requirement says 'show trends and let users drill down', the answer is embedded Power BI — not a PCF chart.
Decision Criteria
| Option | Use when | Skillset | ALM and cost |
|---|---|---|---|
| Business rule | Validation, defaults, show/hide | Maker | Solution-aware; no extra cost |
| Cloud flow | Automation and integration | Maker | Solution-aware; license-dependent |
| Custom connector | Reusable REST API access | Maker with dev support | Solution-aware; premium license |
| PCF code component | Custom UI rendering | Pro dev (TypeScript) | Solution-aware; premium app license |
| Plug-in / custom API | In-transaction server logic | Pro dev (C#) | Solution-aware; Dataverse capacity |
| Webhook + Azure Function | Heavy or shared external logic | Pro dev | Azure DevOps ALM; Azure consumption |
Judge every option on four axes: the skillset available on the team, whether the artifact participates in solution ALM, the licensing or Azure cost it introduces, and who will support it after go-live.
Exam Traps
- Do not code what configuration can do: if a business rule, calculated column, or standard control satisfies the requirement, every code-based option is wrong.
- Data or action gap means custom connector; pixel gap means PCF. Swapping these two is the most common extensibility error.
- Custom connectors are always premium — a 'free standard connector' answer is wrong the moment the API is proprietary.
- Only a plug-in (or a custom API backed by one) guarantees server-side, in-transaction execution on Dataverse data.
- A webhook deploys nothing to Dataverse; the logic lives entirely at the receiving endpoint.
A company uses a proprietary shipping API with a REST endpoint and an OpenAPI specification. Makers need to quote rates from a canvas app, refresh rates in a nightly cloud flow, and let a Copilot Studio agent quote rates on demand. What is the best extensibility option?
A requirement says: when an order's Status is set to Approved, the Approval Date column must become required, and users should see an error if it is blank. The logic must be maintainable by the app's functional consultants without deploying code. Which option should you recommend?