AB-410 Building Intelligent Applications Questions and Answers

A business process flow is designed to present a visible sequence of stages and steps on a model-driven app record. The adoption duties naturally form the ordered stages Commitment, Pre-pickup, and Pickup, with the individual signature, deposit, surgery, date, payment, and handoff tasks configured as data steps within those stages. This guides administrative staff through the required order and clearly shows current progress. A business rule performs conditional form logic such as setting values, changing visibility, making fields required, or displaying errors; it does not provide the requested multi-stage duty list and process bar. A business unit is an organizational security boundary and has no role in representing procedural steps. The supplied answer A is therefore incorrect and has been changed to B. The separate date-validation requirement can still be implemented with a business rule while the overall adoption workflow is implemented as the business process flow. Microsoft documents business process flows as a way to ensure users enter data consistently and follow the same stages when completing organizational processes.

Adopters: None - Organization - None. Dogs: None - Organization - Organization. Residents: None - Organization - Organization.

Care staff must be able to identify adopters for upcoming meetings but must not add or modify adopter information. The Contact or Adopter table therefore requires organization-level Read with no Create or Write. Dogs are organization owned, and staff must view dog information and update the Weight column through the Dog form embedded in Resident. They consequently require organization-level Read and Write but no Create, because only administrative staff may add dogs. Residents are created automatically when a Dog is created, so care staff do not require Create. They do require organization-level Read and Write to view and maintain residency details such as food type and amount.

Feature: Audit changes to its data. Table: Resident.

Food type and amount are columns on the Resident table, so Dataverse auditing must be enabled for that table and for the two relevant columns. The Audit changes to its data setting records create, update, and delete events and captures the user and time associated with audited changes. This directly supports the requirement to identify who changed the values during the preceding three months. The audit-retention policy should therefore retain records for at least that period. The Feeding table is not the correct target because the scenario explicitly states that food type and amount are stored on each Resident row. A timeline displays activities and notes but does not automatically provide field-level before-and-after history. Audit user access records access events and is not a substitute for auditing data changes. Environment-level auditing must also be enabled before table and column auditing produces history. Microsoft documents that audited changes can be retrieved with Changed By and Created On information, allowing authorized staff to determine who made each modification and when it occurred.

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

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

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

Changing the username directly in the app’s Dataverse user record does not meet the goal. The application user entry is synchronized from Microsoft Entra ID and is not the authoritative place to change a person’s sign-in identity. A direct modification may be blocked, overwritten by synchronization, or leave the tenant sign-in name unchanged. The correct operation is to update the existing user account in Microsoft 365 or Microsoft Entra administration so the same directory object is retained and its new user principal name flows into the Power Platform environment. Retaining the object identity is what protects ownership and application history. The spelling difference in the proposed “Elizabeth” record also creates an additional risk of modifying the wrong identity. After the tenant update, administrators should verify synchronization and mailbox approval without creating a replacement user. The AB-410 profile expects collaboration with identity administrators for “roles, identity, and authentication,” and the data-model objective includes “configure security.” Because the proposed app-record edit bypasses the identity source, the answer is No.

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

Enable users to open the app — Share the app and assign appropriate security roles; Diagnose access — Run the App access checker

To enable users to open the model-driven app, the maker must share the app with the appropriate security roles and ensure users are assigned those roles. App visibility alone is not sufficient if the role lacks privileges to required Dataverse tables, but role-based sharing is the central app-access control. When a particular user still cannot open the app, the App access checker is the targeted diagnostic. It evaluates the user’s app sharing, security roles, licensing, and related configuration and reports the access path or missing requirement. The solution checker reviews solution quality and component issues; it does not diagnose a user’s effective app entitlement. Reviewing table permissions manually can be useful after a specific role problem is identified, but it is not the broad first diagnostic represented in the answer area. The checker should be run against the affected user identity and the exact app. This maps directly to the Study Guide objectives “configure access to model-driven apps” and “configure security.” The two actions establish access and then provide a supported way to determine why effective access differs from the intended configuration.

Study Guide reference/topic: “Create model-driven apps — Configure access to model-driven apps.” AB-410 Study Guide | Microsoft Learn technical reference

Require completion before progression — Set the data step as Required; Send an approval — Add a Power Automate cloud flow

The data step in the business process flow must be marked Required. That setting prevents the user from progressing past the stage until the mandatory value is supplied, while keeping the enforcement within the process as required. Setting the underlying column to Business Required would enforce entry outside the business process flow as well, which violates the stated scope. To create and send the approval, add a Power Automate cloud flow associated with the process transition or stage logic. The flow can create the approval, assign it to the record owner, and deliver the request through Microsoft Teams. A classic workflow step is a legacy mechanism and does not provide the modern Teams approval orchestration required. The cloud flow should use the row identifier and owner information from the process context, and should record approval status to avoid duplicate submissions. The Study Guide explicitly includes “configure business process flows” and “manage approvals by using cloud flows.” The correct mapping combines process-local data enforcement with a cloud flow for the background approval action.

Study Guide reference/topic: “Implement business and process logic — Configure business process flows.” AB-410 Study Guide | Microsoft Learn technical reference

The expectations portion should specify that the summary is formatted as a clear bullet list with short sentences. Expectations describe what the generated output should look like and the constraints it must satisfy. Option C therefore defines both structure and writing style in testable terms. Highlighting themes and features describes content goals but is less specific about output form. “Use the PDF and the business glossary” belongs in the input or grounding context, where the prompt identifies the source report and approved terminology. “Create a Microsoft Word document” describes a downstream file or delivery action rather than the text-generation expectations; the prompt produces content, while the app or flow can create the Word artifact. The custom prompt should separately define the role, task, inputs, glossary grounding, and output expectations so each concern is explicit. The source answer A has been corrected to C. The Study Guide covers “build prompts,” “add knowledge to a prompt,” and “add inputs to a prompt.” A precise bullet-format expectation helps produce consistent, professional output from the supplied report and glossary.

Study Guide reference/topic: “Create prompts and models in AI Hub — Build prompts and add knowledge.” AB-410 Study Guide | Microsoft Learn technical reference

The solution must contain the Power Automate cloud flow because that flow implements the service-request completion automation: it evaluates related Qualification rows, updates the Service Request, and sends the client email. It must also contain the connection reference used by the solution-aware flow. A connection reference is a portable solution component that identifies the connector binding while allowing each target environment to supply its own authenticated connection. The actual connection stores credentials and is environment-specific; it is not the component that should be transported as part of the managed solution. A business process flow guides users through interactive stages but does not replace the event-driven cloud flow required by the scenario. Including both the cloud flow and its connection reference also addresses the reported missing-dependency import failure. The makers should verify that every connector action in the flow uses a connection reference included in the same solution and that target environments map those references to service-account connections during deployment. Microsoft documents that solution-aware flows bind to connection references and receive target-environment connections during import.

A Managed Environment adds centralized governance and operational capabilities to a standard Power Platform environment. It is the environment type intended for administrators who need organization-wide visibility, governed settings, and platform-native application lifecycle features. Managed Environments can participate in Power Platform pipelines, apply environment groups and rules, surface usage insights, and enforce governance consistently across existing and newly managed environments. A Developer environment is a personal build space and is not the correct production governance boundary. A Sandbox supports testing and administrative reset or copy operations but does not, by itself, deliver the full managed-governance feature set. A Production environment is suitable for live workloads, yet it must be enabled as a Managed Environment to meet the stated centralized controls. The terms are not mutually exclusive in every administrative screen—a production or sandbox environment can be managed—but among the given environment-type choices, Managed is the intended answer. Microsoft documents Managed Environments as the governance layer for administering Power Platform at scale.

Logical navigation groupings — Customize the site map; Required tables in navigation — Add tables to app designer

The site map organizes a model-driven app’s navigation into areas, groups, and subareas, so customizing it is the action that creates logical business-process groupings. Tables and other pages are exposed through those subareas. To ensure that only required table data is included, the maker adds the selected tables to the app in the app designer and omits unrelated tables. Configuring app settings changes runtime features and behavior but does not define the navigation hierarchy. App properties hold metadata such as name, description, or icon and likewise do not select the operational data components. The final app should be validated for dependencies because adding a table can also require forms, views, charts, and security-role privileges. Navigation visibility does not itself grant data access; users still need the relevant Dataverse permissions. The Study Guide’s model-driven app objectives include “compose a model-driven app” and configure its forms, views, and access. The correct mapping therefore uses the site map for information architecture and the app designer’s table selection for component inclusion.

Study Guide reference/topic: “Create model-driven apps — Compose a model-driven app.” AB-410 Study Guide | Microsoft Learn technical reference

Add the Devices table to the solution: Add object. Add only the Status column change: Add object and select the Status column only. Export as a managed solution.

Add object is used to include the existing Devices table in the solution and to choose the specific table object that must travel with it. To minimize the deployment, add only the Status column rather than all table objects. Add required components should be used only when the selected component has dependencies that are necessary for correct operation; it is not a substitute for deliberately selecting the changed column and may expand the solution beyond the requested scope. After adding the Review choice value, publish the customization, verify the solution components, and export the solution as managed so the promoted component cannot be edited directly in the test environment. The environment receiving the solution should be checked for compatible dependencies and the import should be validated before broader release. The solution version should be incremented so the deployment remains traceable. Microsoft solution guidance supports selective table-object inclusion and managed deployment to keep downstream customizations controlled.

Disabling the Searchable property for the unwanted address columns removes them from maker-facing query and view design experiences where searchable columns are offered for views, charts, and Advanced Find-style filtering. That directly addresses the requirement that users should not be able to select those columns while creating views and filters. Column-level security is not a metadata-hiding feature: removing Read access protects values at runtime but does not reliably remove the column definition from customization or query interfaces. A business rule can change controls on forms, but it does not govern which columns are available to a view designer. Deleting standard address columns is destructive, can break dependencies, and is unnecessary. The original answer A therefore over-applies data security to what is fundamentally a discoverability/configuration requirement; D is the verified answer. If the values themselves are sensitive, column security may be implemented in addition, but that is a separate requirement. This decision aligns with the AB-410 objectives “create and modify columns” and “configure public views,” particularly the use of column metadata to shape view and filter authoring.

Study Guide reference/topic: “Build data models — Create and modify columns; Configure public views.” 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.

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

The App access checker requires the individual user as its input, so the new QA tester’s email address is the appropriate value. The checker evaluates why that user can or cannot open a model-driven app by examining app sharing, assigned security roles, licenses, and relevant environment access. A Microsoft Entra security-group name or a Dataverse group-team name is not the subject of the diagnostic; those objects can influence access, but the tool performs its analysis for a specific user identity. The manager’s username is unrelated to the tester’s failure. In this case, group-team membership may be synchronized or evaluated indirectly, and the checker can reveal the effective access result even when the user is not visibly listed as a conventional team member. Administrators should also verify that the environment security group, license assignment, app sharing, and table privileges are aligned. Its content maps to the Study Guide objective “configure access to model-driven apps,” including use of the App access checker for targeted diagnosis.

Study Guide reference/topic: “Create model-driven apps — Configure access to model-driven apps.” AB-410 Study Guide | Microsoft Learn technical reference

Senior Technicians — Security roles; Hot Assets — Sharing

The Senior Technicians public view should be restricted by security roles. Public views are solution components and can be included in a model-driven app, but role-based view access is the correct mechanism when only a defined class of users should see the view in the view selector. The relevant manager or senior-technician role is granted access while other roles are excluded, allowing each audience to see context-relevant views without changing table-level data privileges. Hot Assets is a personal view created by an individual tester. Personal views are user-owned artifacts and are made available to colleagues by sharing them with users or teams. Sharing the view with the Testers team is therefore the direct way to make it usable by the whole testing group. Owner teams and business units concern record ownership or security scope; they do not convert a personal view into a shared view by themselves. The AB-410 Study Guide lists “configure access to forms and views for model-driven apps.” These two configurations apply the platform’s distinct access models: role assignment for a public system view and explicit sharing for a user-owned personal view.

Study Guide reference/topic: “Create model-driven apps — Configure access to forms and views.” AB-410 Study Guide | Microsoft Learn technical reference

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