App Access Checker Input for Model-Driven App Access

This is a case study. Case studies are not timed separately from other exam sections. You can use as much exam time as you would like to complete each case study. However, there might be additional case studies or other exam sections. Manage your time to ensure that you can complete all the exam sections in the time provided. Pay attention to the Exam Progress at the top of the screen so you have sufficient time to complete any exam sections that follow this case study. To answer the case study questions, you will need to reference information that is provided in the case. Case studies and associated questions might contain exhibits or other resources that provide more information about the scenario described in the case. Information provided in an individual question does not apply to the other questions in the case study. A Review Screen will appear at the end of this case study. From the Review Screen, you can review and change your answers before you move to the next exam section. After you leave this case study, you will NOT be able to return to it. To start the case study To display the first question in this case study, select the “Next” button. To the left of the question, a menu provides links to information such as business requirements, the existing environment, and problem statements. Please read through all this information before answering any questions. When you are ready to answer a question, select the “Question” button to return to the question. Background Contoso Ltd. is a global renewable energy provider that operates wind farms and solar installations. The company is modernizing its maintenance and operations platform. The company plans to implement a Microsoft Power Platform solution for the operations team. The implementation will include Microsoft Dataverse, a model-driven app, and Power Automate cloud flows. The company is building and testing a new model-driven app named Operations. The solution will support operations managers, regional coordinators, and field technicians. The app must integrate with an external cloud-based system that manages onboarding of field technicians. Contoso Ltd. plans to improve data quality and enforce consistent business logic across the app and automation processes. Technical environment Contoso Ltd. has an Identity and Access Management (IDAM) department that manages security. The company has one Power Platform environment named Production, where all building and configuration take place. Auditing is disabled. The Production environment has the following security configurations: IDAM has a Microsoft Entra security group named Contoso Ltd. QA. This security group will assign all members a Power Apps license. IDAM created a Quality Assurance security role that grants read and write access to all custom tables. IDAM also created a team named Testers in Dataverse, of a Microsoft Entra group team type. The team is configured for the Contoso Ltd. QA security group. The Testers team is assigned the Quality Assurance security role. Microsoft 365 environment All Contoso Ltd. managers are included in a Microsoft 365 group named Managers. The group is NOT enabled for email. The company shares a SharePoint list with a key customer: Alpine Ski House. Alpine Ski House staff members can add new maintenance requests, which are then checked and marked as reviewed by Contoso Ltd. Current issue: A new QA tester joins Contoso Ltd. The IDAM department adds the new tester to the Contoso Ltd. QA security group. However, the new tester is not listed in the Testers team as a member. Other applications: A separate software-as a-service (SaaS) solution named TechCheck manages technician onboarding. The TechCheck solution is set up as follows: TechCheck assigns a unique number named Ref to all technicians. Users cannot make changes to the TechCheck data model. Users cannot use the same TechCheck ref on more than one Technician row. Automation requirements Contoso plans to use Power Automate to develop a Maintenance Request Approval flow. The flow must meet the following requirements: Create a Maintenance Request row in Dataverse when either of the following occurs: An item is added to the SharePoint list by the customer with the Priority property set to High. Any item is checked and marked as reviewed by a Contoso Ltd. representative. Seek maintenance request approvals from managers through both email and a Microsoft Teams message after they have been reviewed: Requests require approval from all managers. If one manager rejects the request, approval must not be granted. The result of the approval request must be sent to the initial reviewer in an email. The subject line must set the response as either Approve or Reject. Contoso Ltd. requires the following table logic: If a user tries to enter a price greater than the cost on a new Asset row, the row must display an inline error message. If a user tries to save changes to a Technician row where the TechCheck ref column is empty, the action must be prevented and a message explaining the action must be displayed. Any updates made to Technician profiles in TechCheck must be mirrored in Dataverse by using a custom integration. The developers building the integration require an index for performant searches on the Technician table. Data model and app design Contoso Ltd. plans to use Dataverse as its central data platform. Log storage must be minimized. Tables The following tables are required for data modeling and the app design: Assets: Stores information about solar panels and wind turbines Maintenance Requests: Tracks issues and maintenance activities. The table must include the following columns: Request ID (auto-number) External Request Code (text) Assigned Technician (lookup to Technicians) Report (lookup to Maintenance Reports) Technician updated (Yes/No) Maintenance Reports: Tracks the results of maintenance reports Technicians: Stores technician assignment data. The table must include the following columns: Full Name (Text) Mobile phone number (Text) Email (Text) Seniority (Choice) TechCheck ref (Text) Data modeling The data model must provide the following functionality: Maintenance Requests must: be uniquely identifiable across systems. have two inactive statuses, Cancelled and Duplicate. If a new option is added to an existing set of options, it must be made available automatically for selection on all columns that use the set. A new column named Priority must be added to multiple tables. Users must be able to select only one option from the following set per row: Low Medium High Critical Changes to the Technician column on Maintenance Requests must be tracked for compliance purposes. Rows must include the names of previous and current technicians and the time of the change. Relationship requirements One asset can be related to many maintenance requests. A maintenance request can have many assets. A maintenance request can have only zero or one maintenance report. Only one Technician can be related to a Maintenance Request at a time. When a Maintenance Request is deleted, any Maintenance Reports associated with it must also be deleted, but this action should be prevented if there is value in the Technician lookup. When a Maintenance Request is assigned to a different owner, the Maintenance Report associated with it must be reassigned to the new owner as well, but the associated Technician should stay with the current owner. App design The Technicians table contains the following public views: Senior Technicians Junior Technicians The Senior Technician view must be available through the table list view selector to a set of specific users only. A tester creates a personal view named Hot Assets on the Assets table. The tester recognizes that the view is useful for the entire testing team. The view must be made accessible to the team. You need to run the App access-checker. What should you use as the input?