PL-400 Practice Questions

Division: Since a division typically represents a predefined list of categories (e.g., North, South, East, West), an Option Set (now known as a Choice column in Dataverse) is the standard type used to provide a dropdown list of fixed values.

End date: For tracking a specific calendar day without a time component, Date Only is the most precise data type. Using "Text" would prevent date-based logic/sorting, and "Duration" measures elapsed time (minutes/hours), not a deadline.

Tournament owner: In Dataverse, "Owner" is a system-managed field, but for a custom field referring to a specific User or Team record, a Lookup is the appropriate type to create a relationship between tables.

Microsoft Learn: "Types of columns" in Dataverse. Section: "Choices (Option sets)". Dataverse Column Types

Microsoft Learn: "Date and Time column" documentation. Section: "Date Only behavior". Date and Time Behavior

Microsoft Learn: "Create a relationship between tables using a lookup column". Lookup Columns

Microsoft Power Platform Documentation: "Standard columns - Owner field". Explains the distinction between the system 'Owner' and custom lookups.

For the first requirement, background checks are inherently asynchronous processes performed by external entities. An Event-based pattern is the standard architectural choice, as it allows the system to remain decoupled and react only when the completion "event" occurs (e.g., via a webhook or service bus message), rather than polling (Pull) or maintaining a synchronous connection.

For the second requirement, the Upsert operation is the most efficient method for synchronizing external data into Dataverse. It allows the system to update the existing record's stage/status if it exists, or create a new one if it does not, without requiring a separate "check for existence" step. While Alternate keys are often used as the mechanism to identify records during an Upsert, the action itself of applying the change is the Upsert operation.

Microsoft Learn. (2023). Use Upsert to insert or update a record. [Online]. Available: https://learn.microsoft.com/en-us/power-apps/developer/data-platform/use-upsert-insert-update-record

Microsoft Learn. (2023). Integration patterns for Microsoft Power Platform. Section: "Asynchronous integration patterns."

Microsoft Azure Architecture Center. (2023). Event-driven architecture style. [Online]. Available: https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven

Microsoft Learn. (2022). Define alternate keys to reference records. [Online]. Available: https://learn.microsoft.com/en-us/power-apps/developer/data-platform/define-alternate-keys-entity

The System Customizer role allows users to create and modify customizations (entities, fields, forms) but restricts access to the data within those entities unless they created them. This adheres to the principle of least privilege for app creators. Conversely, the System Administrator role is the only one that possesses "All" access across all records and system settings by default. While both roles can customize, the System Customizer cannot view all stored data, making it the correct choice for the first two requirements. Only the System Administrator has the inherent permission to view all data stored in system entities.

Microsoft Learn Documentation: "Predefined security roles - System Administrator and System Customizer." Section: Security roles and privileges. (https://learn.microsoft.com/en-us/power-platform/admin/database-security#predefined-security-roles)

Microsoft Power Platform Admin Guide: "About security roles." Paragraphs detailing the differences between administrative roles and customizer roles regarding data access.

Microsoft Learn: "Create or edit a security role to manage access." Document ID: admin-security-roles-privileges.

Dynamics 365 Implementation Guide: Section on Identity and Security, focusing on the principle of least privilege in environment administration.

The proposed solution correctly implements a durable and reliable integration pattern. Registering an asynchronous step on a service endpoint connected to an Azure Service Bus queue effectively decouples Dataverse from the target system. If the Azure Function or the target system is unavailable, messages are safely stored in the queue until they can be processed, thus preventing data loss. The asynchronous post-operation execution ensures that the main Dataverse transaction is not blocked and that only successfully created records are sent, fulfilling all the stated requirements for a resilient integration.

B. No: This option is incorrect. The solution uses a standard, recommended architecture for one-way, asynchronous integration from Dataverse. The use of an Azure Service Bus queue is specifically designed to handle temporary unavailability of downstream components, which directly addresses the core requirement of the scenario.

1. Microsoft Dataverse Developer Guide, "Azure integration with Microsoft Dataverse": This document outlines the use of Azure Service Bus for creating a secure and reliable communication channel between Dataverse and external applications. It states, "This capability is especially useful in keeping disparate Dataverse systems or other Dataverse servers synchronized with business data changes."

Source: Microsoft. (n.d.). Azure integration with Microsoft Dataverse. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/power-apps/developer/data-platform/azure-integration

2. Microsoft Dataverse Developer Guide, "Event Framework": The documentation on the asynchronous service explains its resilience. It states, "Asynchronous plug-ins are queued... If an asynchronous plug-in fails, the platform will try to run it again." This built-in retry mechanism in Dataverse handles transient connectivity issues to the Service Bus.

Source: Microsoft. (n.d.). Event Framework. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/power-apps/developer/data-platform/event-framework#asynchronous-service

3. Azure Service Bus Documentation, "Service Bus queues, topics, and subscriptions": This documentation describes queues as a durable messaging solution. Messages sent to a queue are held until a consuming application is ready to receive and process them, which is the fundamental principle that prevents data loss when a component is unavailable.

Source: Microsoft. (n.d.). What are Service Bus queues, topics, and subscriptions?. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-queues-topics-subscriptions#queues

The function showMsgOnField(exContext, where, sMessage) is triggered by the Business Phone OnChange event.

1. Parameters: The handler passes telephone1 and mobilephone as arguments. In the code, where receives "telephone1" and sMessage receives "mobilephone".
2. Logic: * formContext.getControl(where).setNotification(sMessage, msgId): Sets a control notification on the field named telephone1. However, the visual exhibit shows "Business Phone" which is the display name for the telephone1 schema name. Since sMessage is "mobilephone", this text appears in the field notification.

• formContext.ui.setFormNotification(sMessage, 'INFO', msgId): Displays the content of sMessage ("mobilephone") as a top-level form notification. The value of where ("telephone1") is used as the target location/ID, not the message content.

Microsoft Learn (Power Apps/Dynamics 365): Client API Reference - setNotification (Client API reference). It specifies that the first parameter is the message string.

Microsoft Learn: setFormNotification (Client API reference). Confirms the first parameter is the message to display.

Microsoft Dynamics 365 SDK: Understand the execution context and the form event pipeline. Explains how parameters defined in the Event Handler properties are passed to JavaScript functions.

Microsoft Learn: getControl (Client API reference). Explains how to access a specific control on the form using its name.

The question requires an expression suitable for a time-based trigger condition related to a record's creation date. The DIFFINDAYS(date1, date2) function is specifically designed for this purpose within Dataverse calculated columns. It calculates the difference in days between two dates. Using DIFFINDAYS(CreatedOn, now()) directly computes the age of the account record in days. This resulting integer value can then be easily used in a Power Automate flow trigger condition, a business rule, or a view filter to initiate an action when the account reaches a specific age (e.g., when the result is greater than or equal to 10).

A. ADDWEEKS(1, CreatedOn) calculates a future date. While usable in a comparison, it is less direct than calculating the elapsed time.

B. ADDDAYS(10, CreateOn) calculates a future date. It is an indirect method for checking a record's age compared to DIFFINDAYS.

C. SUBTRACTDAYS(10, Now()) calculates a past date. This can be used for comparison but is less straightforward than directly calculating the age of the record.

E. DIFFINWEEKS(now, 1) is syntactically incorrect. The DIFFINWEEKS function requires two date/time parameters, not a date and an integer.

1. Microsoft Learn | Dataverse Documentation. Define calculated columns to automate manual calculations. This document lists the available functions for calculated columns in Dataverse, including DIFFINDAYS, ADDDAYS, and NOW().

Reference: Under the section "Date and Time functions," the table explicitly lists DIFFINDAYS (date and time, date and time) with the description "Returns the difference in days between two Date and Time columns." The NOW() function is also described as returning the current date and time.

2. Microsoft Learn | Dataverse Documentation. Work with operators and functions in business rules, business process flows, and classic workflows. This guide details the functions available in the classic workflow and business rule editor.

Reference: The section on "Date/Time Functions" confirms the availability and syntax of functions like DIFFINDAYS, which are used to build conditional logic based on date differences.

action: In Power Automate, an action is the operation that the flow performs after a trigger or condition is met. Sending an outbound text (SMS or notification) is a discrete task performed by a connector, categorizing it as an action.

condition: A condition is a logic gate that evaluates a statement as true or false. Testing if there are specifically nine customers involves a comparison (e.g., Count is equal to 9), which defines a condition block.

expression: Expressions are used to perform calculations, manipulate data, or retrieve specific values. Determining the number of customers (the count) typically requires an expression (such as the length() function) to evaluate a collection of data.

Microsoft Learn: "Get started with expressions in Power Automate." This documentation defines expressions as functions used to manipulate data or perform calculations within a flow.

Microsoft Learn: "Add a condition to a cloud flow." This guide explains that conditions are used to execute different actions based on whether a specific logic test (like a count threshold) is met.

Microsoft Learn: "Common Data Service (Dataverse) connector - Actions." Lists "Send an email" or "Create a record" as actions, which applies to "outbound text" functionality.

Microsoft Power Platform Fundamentals (PL-900): Official curriculum, Module "Introduction to Power Automate," Section: "Flow control elements."

Power Automate is the most suitable mechanism for this scenario. It provides a comprehensive, low-code solution for the entire process. It can be configured with a trigger to monitor various sources for resume submissions, such as an email inbox or a SharePoint folder. It can then use the AI Builder's prebuilt resume processing model to parse the document and extract relevant information. Finally, the native Microsoft Dataverse (formerly Common Data Service) connector can be used to create or update records with the extracted contact and skills data, fulfilling all requirements of the task.

B. Common Data Service plug-in: Plug-ins execute server-side code in response to events within Dataverse (e.g., creating a record), but they cannot monitor external sources like a file drop location.

C. Web API: The Dataverse Web API is a RESTful endpoint used to interact with data. It is a passive interface that must be called by another application; it does not actively monitor for new submissions.

D. Custom workflow activity: These are components of classic Dataverse workflows, which are triggered by internal Dataverse events. They are not designed to monitor external systems for new files.

1. Microsoft Learn, Power Platform documentation. "Use the resume processing prebuilt model in Power Automate". This document explicitly details the use case of creating a Power Automate flow that is triggered by a new email with an attachment, uses AI Builder to process the resume, and then saves the extracted information. This directly matches the question's scenario.

2. Microsoft Learn, Power Platform documentation. "Overview of cloud flows". This page describes how Power Automate cloud flows can be triggered automatically, instantly, or via a schedule, and can connect to hundreds of data sources, which is essential for the "monitor submissions" requirement.

3. Microsoft Learn, Power Platform documentation. "Use plug-ins to extend business processes". Section: "When to use plug-ins". This document clarifies that plug-ins are used to initiate automated processes when a specific event occurs on the Dataverse server, distinguishing them from Power Automate which connects external events to Dataverse.

4. Microsoft Learn, Power Platform documentation. "Use the Microsoft Dataverse Web API". This source describes the Web API as an OData v4 service endpoint, confirming its role as a programmatic interface for data operations, not an automation or monitoring engine.

To track specific metadata (the visit date) for a many-to-many relationship between Contacts and Countries, a standard native N:N relationship cannot be used because native intersect tables are hidden and do not support custom columns. Instead, you must implement a manual intersect entity (ContactCountry).

The sequence begins with creating the Country entity to serve as a reference. Next, you create the ContactCountry entity with two N:1 (Many-to-One) relationships pointing to Contact and Country respectively; this structure allows one contact to have many visit records. Finally, you configure the ContactCountry form by adding the lookup fields and the specific Date field required to satisfy the business requirement of tracking when the travel occurred.

Microsoft Learn (Power Apps Documentation): Create a Many-to-Many table relationship in Microsoft Dataverse using Power Apps portal. This documentation specifies that native N:N relationships do not allow custom fields, necessitating manual intersect tables for scenarios requiring additional data like "visit dates."

Section: "Many-to-many (N:N) relationships"

Microsoft Learn (Dataverse Developer Guide): Work with relationship metadata. Explains the architecture of OneToManyRelationshipMetadata and how manual intersect entities function via lookup fields (N:1).

Document ID: "Table relationships overview"

Microsoft Power Platform University Courseware: Module: Data Modeling in Dataverse. Provides guidance on choosing between native and manual N:N relationships based on whether the relationship itself requires attributes.

Unit: "Advanced Relationship Configurations"

Statement 1 (No): The code explicitly calls service.Retrieve with a ColumnSet("fullname"). In Dataverse plug-ins, if a column is not included in the Target (InputParameters) or explicitly retrieved via the IOrganizationService, the value is not available in the execution context.

Statement 2 (Yes): Plug-ins are highly customizable. By modifying the FetchXML query to target an "interviewer" entity or by adding conditional logic within the foreach loop, the same assembly and class can be repurposed to send notifications to different roles.

Statement 3 (No): The foreach loop iterates through all entities returned by the FetchXML query on the pro_application table. If an applicant (contact) has multiple application records associated with different recruiters (or even the same one), the code will trigger SendEmail for every record found in the result set.

Microsoft Official Documentation: Understand the data context, "InputParameters," and "Entity Class." Documenting that only attributes in the Request or retrieved via Service are available.

Microsoft Official Documentation: Retrieve multiple with FetchExpression, explaining how RetrieveMultiple returns an EntityCollection that is iterated via loops.

Microsoft Power Platform Developer Guide: Use Plug-ins to extend business processes, Section: "Register a plug-in," regarding the flexibility of plug-in logic for different business requirements.