AB-410 Building Intelligent Applications Questions and Answers

Maintenance Report — Parental; Technician — Referential, Restrict Delete

The Maintenance Report relationship must use Parental behavior. A report is operationally dependent on its Maintenance Request: deleting the request must delete the related report, and assigning the request to a new owner must also assign the report. Parental behavior supplies cascading behavior for operations such as Assign and Delete, which matches both requirements. The Technician relationship must use Referential, Restrict Delete. The technician is an independent master record and must not be reassigned merely because a maintenance request changes owner. Restrict Delete also protects the related record arrangement where deletion would violate an existing reference. Referential, Remove Link would clear the lookup instead of blocking the relevant deletion, so it does not meet the stated protection requirement. This decision aligns with the AB-410 Study Guide objective “configure table relationships,” including selection of relationship behavior according to ownership and cascade requirements.

Study Guide reference/topic: “Build data models — Configure table relationships.” AB-410 Study Guide | Microsoft Learn technical reference

TechCheck ref must be configured as Required before it is used as an alternate key. An alternate key is intended to identify a Dataverse row by a stable business value supplied by an external system. Allowing the key column to be empty would defeat the onboarding integration’s requirement that every technician be addressable by the external reference. The case also states that the same TechCheck reference cannot be used on more than one Technician row; the alternate key enforces uniqueness through its Dataverse index after the key is activated. Searchable controls whether the column is available in search experiences, but it does not guarantee that a value is supplied. Column security governs who can read or update a value, and auditing records changes; neither property establishes the required identity. A sound implementation also validates existing data for nulls and duplicates before activating the key, because key creation can fail while invalid rows remain. This is covered by the Study Guide objectives “configure table properties” and “create and modify columns.” Required is therefore the setting that supports a complete, consistently populated external business key.

Study Guide reference/topic: “Build data models — Configure table properties.” AB-410 Study Guide | Microsoft Learn technical reference

A global choice provides one centrally maintained option set that multiple Dataverse columns can reference. This directly satisfies the requirement that Priority must be added to several tables and that a newly added option must become available automatically wherever the shared choice is used. Microsoft’s Dataverse documentation states that columns can refer to a “common set of global options.” Maintaining the values centrally prevents separate Priority columns from drifting out of synchronization.

A local choice is defined specifically for one column. Adding a value to one local choice would not update corresponding columns on other tables. Status reason is tied to a row’s active or inactive state and is unsuitable for general priority classification. A formula column calculates a value; it does not provide a centrally managed, user-selectable list.

Because users must select one value, the column should be a single-select Choice referencing the global Priority choice, not a multi-select Choices column.

The solution requires an AI Builder prompt, a cloud flow, and a Dataverse table. The prompt performs the autonomous semantic analysis of each feedback item, including sentiment or other instructed classifications. The cloud flow supplies the event-driven orchestration: it retrieves new feedback, calls the prompt, interprets the result, writes the output, and branches to an escalation action when sentiment is negative. Dataverse provides persistent, queryable storage for the original feedback, model result, status, and reporting fields. A canvas app may be useful for reviewing results but is not required for autonomous execution. A business rule can validate or adjust Dataverse data but cannot independently call the generative model and orchestrate external escalation. The flow should include explicit failure handling, confidence or result validation, and an idempotent design so retries do not create duplicate escalations. Approved data policies must also permit the connectors used by the flow. The Study Guide covers “consume a prompt in cloud flows,” “configure cloud flow actions,” and the creation of Dataverse-backed business solutions. A, B, and E form the complete analysis, automation, and persistence architecture.

Study Guide reference/topic: “Create cloud flows; Create prompts and models in AI Hub.” AB-410 Study Guide | Microsoft Learn technical reference

Technician name on one screen — Context variable; Work orders — Collection; Logic statements — Named formula

A context variable should hold the technician’s name because the value is required only on the home screen. Context variables are screen scoped, which limits the state to the place where it is needed and avoids creating wider application dependencies. A collection is the correct structure for work orders because it stores a table of records that a gallery can enumerate, filter, and display. A named formula is appropriate for reusable logic statements that should be calculated consistently without imperatively setting a variable. The original answer image selects a global variable for the technician name, but that scope is broader than required; the image is retained unchanged while the verified mapping uses Context variable. A global variable is appropriate when a scalar value must be available across screens, not when the requirement explicitly limits persistence to one screen. The app should also avoid loading an unnecessarily large work-order collection and should delegate filtering to the data source where possible. The Study Guide directly lists “manage variables and collections” and “named formulas” under Create canvas apps. The verified mapping applies each state mechanism at its intended scope and data shape.

Study Guide reference/topic: “Create canvas apps — Manage variables and collections; Create reusable components.” AB-410 Study Guide | Microsoft Learn technical reference

A custom prompt is the native low-code mechanism for generating an inspection report from current app data while following the company’s existing template instructions. The maker can define inputs for the inspection fields, specify required sections, tone, order, and formatting, and invoke the prompt from the new app. This keeps the report-generation experience within Power Platform and minimizes custom AI development. A paginated report is well suited to deterministic, pixel-precise reporting, but it does not perform the requested generative composition and generally presents a separate reporting artifact. A Word template performs deterministic field substitution and is useful when no generative rewriting is required; it does not supply the AI-driven custom narrative described in the case. The prompt should be grounded only with approved inspection data, tested for missing inputs, and reviewed for output consistency before production use. The Study Guide covers “build prompts,” “add inputs to a prompt,” and “consume a prompt in apps.” Option C is therefore the component that directly implements native generative inspection-report creation.

Study Guide reference/topic: “Create prompts and models in AI Hub — Consume a prompt in apps.” AB-410 Study Guide | Microsoft Learn technical reference

Business rules and Power Apps component framework controls address the two extensibility requirements while minimizing unnecessary server-side code. A business rule implements supported validation or form/table logic declaratively, making it preferable to a plug-in when the requirement can be satisfied without custom server execution. A Power Apps component framework control packages a reusable custom user-interface component that can be deployed in a solution and used across supported applications. A JavaScript web resource can customize form behavior but is not the preferred reusable control framework for a component with its own rendering and lifecycle. A sitemap controls model-driven app navigation and does not implement either reusable UI or business logic. A plug-in is valid for transactions that require server-side execution, but the case explicitly says to minimize that approach. The AB-410 Study Guide explicitly includes “recommend extensibility options.” Selecting a declarative rule and a PCF control applies that objective to the distinct logic and UI requirements.

Study Guide reference/topic: “Design Power Platform solutions — Recommend extensibility options.” AB-410 Study Guide | Microsoft Learn technical reference

A user-defined function and a component library solve different forms of duplication in the canvas-app estate. A user-defined function centralizes reusable Power Fx logic behind a named, parameterized function, so formulas do not need to be copied and maintained independently. A component library stores reusable canvas components that can be consumed by multiple apps and updated through a controlled component lifecycle. That directly supports the requirement for reusable UI elements across applications. A collection is an in-memory table used during an app session, not a cross-application logic package. A context variable is screen scoped and cannot standardize behavior across apps. A named formula can centralize a reusable calculation within an app, but the question’s paired requirements emphasize reusable logic and reusable UI across multiple applications; the function and component library provide the complete combination. The components should be packaged in solutions and governed through ALM so dependent apps receive tested versions. The Study Guide names “user-defined functions” and “component libraries” within its exact objective to “create reuseable components,” making B and D the aligned selections.

Study Guide reference/topic: “Create canvas apps — Create reusable components.” AB-410 Study Guide | Microsoft Learn technical reference

Calling the prompt from a Power Automate cloud flow provides a reusable service-level entry point that can be invoked by different Power Platform experiences. The flow can accept parameters from each caller, pass those values into the prompt, and then route the generated result to an app, Dataverse, email, or another process. This addresses reuse more effectively than binding the prompt directly to one canvas app. An input variable is necessary for dynamic data, but by itself it does not establish cross-service orchestration; the flow exposes and manages those inputs for multiple callers. Returning JSON can standardize output handling but does not make the prompt reusable by itself. Direct canvas-app invocation is valid for an app-only requirement, not for the stated need to span Power Platform services. The flow should define explicit input types and validate required values so the case’s inconsistent-input problem is not repeated. The AB-410 Study Guide lists both “add inputs to a prompt” and “consume a prompt in cloud flows.” Option B provides the reusable execution layer while allowing dynamic values to be supplied at runtime.

Study Guide reference/topic: “Create prompts and models in AI Hub — Consume a prompt in cloud flows.” AB-410 Study Guide | Microsoft Learn technical reference