Pass the Microsoft Certified: Dynamics 365 Sales AI Consultant Associate AB-410 Questions and answers with ExamsMirror

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.

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.

Component: Business rule. Condition: Pickup date is more than [Spay or neuter date + 2]. Configure the Show Error Message action on the condition ' s false branch.

A business rule is the correct no-code component because the requirement is synchronous form validation with a visible error that prevents an invalid row from being saved. Configure the rule condition by comparing the Pickup date with the Spay or neuter date plus two days. When the condition is false, use Show Error Message on the Pickup date field to tell the user that pickup is too early. The answer screenshot pairs Business rule with an `If(DateDiff(...))` Power Fx expression, but business-rule conditions are assembled with field, operator, and date-offset operands; they are not authored as a formula-column Power Fx expression. A flow would run after a data event and is unsuitable for immediate form validation. A formula column can calculate a value but cannot itself display the required blocking pop-up. The condition must also handle blank dates and the exact policy boundary: ' no sooner than two days ' means a pickup exactly two days later is permitted. Microsoft documents business rules as supporting conditions, date arithmetic, and Show Error Message actions that prevent saving invalid model-driven app data.

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.

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

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

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

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

Security-role-based view access and view filters address different parts of the record-display problem. A view filter constrains the rows returned—for example, Status equals Active and Owner equals Current User—so inactive or unrelated accounts do not appear. Security roles can restrict which public views are available to particular audiences, preventing users from selecting a broader view that was not designed for them. Defining view columns only changes which fields are shown; it does not reduce the number of records. App settings do not provide the row-specific query criteria. Configuring a status column supplies data that a filter can test but does not itself filter the view. Dataverse row-level privileges remain the security boundary: a filtered view improves relevance but should not be treated as protection against access through another query or API. The role should therefore also implement the intended record access depth. The AB-410 Study Guide covers “create and configure views,” “configure access to forms and views,” and “configure security.” Options C and E combine audience-appropriate view availability with the query criteria needed to show the relevant records.

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

Both Formula and Calculated columns can expose a value derived from other Dataverse data without requiring users to store and maintain the result manually. A formula column uses Power Fx and is evaluated from its referenced columns when the value is retrieved. This is suitable for calculating order age from Created On and the current date, subject to the supported Power Fx functions and data types. A classic calculated column also derives its read-only value from a defined expression and can use date-difference functions for an age calculation. BigInt is a stored numeric data type; it would require another process to keep the value current. A Prompt column generates AI content and is unrelated to a deterministic elapsed-time calculation. The important design distinction is that a dynamic age should not be written as ordinary row data, because it becomes stale as time passes. Formula or calculated behavior keeps the displayed result tied to the source expression. The AB-410 Study Guide expressly lists “configure calculated, rollup, and formula columns,” making A and B the two relevant low-code column types.

Study Guide reference/topic: “Implement business and process logic — Configure calculated, rollup, and formula columns.” AB-410 Study Guide | Microsoft Learn technical reference