ExamFinch.com My Study

Study guide

2.3 Recommending Extensibility Options

Practice this exam

Microsoft Certified: Intelligent Applications Builder Associate AB-410

Track your progress as you read

Finished sections get a check mark.

1 Introduction

1.1 About the AB-410 Exam 1.2 How to Use This Study Guide

2 Chapter 2: Designing Power Platform Solutions with AI-Enabled Tools

2.1 Analyzing Requirements and Identifying Components 2.2 Evaluating Built-in Agents for Business Solutions 2.3 Recommending Extensibility Options

3 Chapter 3: Environments and ALM Strategy

3.1 Recommending Environment Types 3.2 Solution and Application Lifecycle Management Strategy

4 Chapter 4: Dataverse Tables and Columns

4.1 Creating and Editing Tables in the Data Workspace 4.2 Configuring Table Properties 4.3 Creating and Modifying Columns

5 Chapter 5: Relationships, AI Data Features, and Data Security

5.1 Configuring Table Relationships 5.2 Configuring Prompt Columns and Row Summaries 5.3 Configuring Public Views and Main Forms 5.4 Configuring Dataverse Security

6 Chapter 6: Model-Driven App Forms and Views

6.1 Creating and Configuring Forms for Model-Driven Apps 6.2 Creating and Configuring Views for Model-Driven Apps 6.3 Creating Generative Pages with Natural Language

7 Chapter 7: Composing, Securing, and Visualizing Model-Driven Apps

7.1 Composing a Model-Driven App 7.2 Configuring Access to Model-Driven Apps, Forms, and Views 7.3 Model-Driven App Charts and Dashboards

8 Chapter 8: Creating and Designing Canvas Apps

8.1 Creating a Canvas App Using Data 8.2 Designing for Accessibility, Performance, Responsiveness, and Usability 8.3 Automating Business Processes from Canvas Apps

9 Chapter 9: Canvas App Components, Variables, and Error Handling

9.1 Reusable Components, Named Formulas, and User-Defined Functions 9.2 Managing Variables and Collections 9.3 Implementing Error Handling in Canvas Apps

10 Chapter 10: Testing Canvas Apps and Creating Agents from Apps

10.1 Testing Canvas Apps with Monitor 10.2 Creating a Copilot Studio Agent from a Canvas App

11 Chapter 11: Cloud Flow Triggers, Connectors, and Approvals

11.1 Recommending Cloud Flow Triggers 11.2 Evaluating and Recommending Connectors 11.3 Managing Approvals with Cloud Flows

12 Chapter 12: Cloud Flow Actions, Control, and Troubleshooting

12.1 Configuring Cloud Flow Actions 12.2 Implementing Flow Control with Conditions and Loops 12.3 Testing and Troubleshooting Cloud Flows

13 Chapter 13: Building Prompts in AI Hub

13.1 Building Prompts from Templates or from Blank 13.2 Adding Inputs to a Prompt 13.3 Adding Knowledge to a Prompt

14 Chapter 14: Prompt Settings, Models, and Consuming AI

14.1 Customizing Prompt Settings and Models 14.2 Consuming Prompts in Apps and Cloud Flows 14.3 Consuming AI Models in Apps and Cloud Flows

15 Chapter 15: Business Rules and Business Process Flows

15.1 Configuring Business Rules 15.2 Configuring Business Process Flows

16 Chapter 16: Calculated Columns and Business Logic Strategy

16.1 Calculated, Rollup, and Formula Columns 16.2 Evaluating Use Cases for Business Logic

2.3 Recommending Extensibility Options

Key Takeaways Explain This Topic AI

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

Last updated: July 2026

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.