nerdexam
Microsoft

PL-200 · Question #332

Case Study 4 - Contoso Suites Background Contoso Suites is an animal shelter that specializes in finding homes for dogs that have been given up by their owners. The shelter can house up to 20 dogs…

The correct answer is None - Organization - None; None - Organization - None; None - Organization - Organization. This question tests understanding of Dataverse security roles, specifically how record ownership (User-owned vs. Organization-owned) and data usage patterns influence the scope of Create, Read, and Write privileges in a single business unit environment, using abstract privilege…

Question

Case Study 4 - Contoso Suites Background Contoso Suites is an animal shelter that specializes in finding homes for dogs that have been given up by their owners. The shelter can house up to 20 dogs. The shelter is implementing one model-driven Power Apps app to track the dogs and schedule meetings with potential adopters. No other apps will be created. The model-driven app uses Dataverse with out-of-the-box functionality when possible. Dataverse is set up with the following configuration: - The solution prefix "cs" is used for all new components. - Only the root business unit is used. - All tables are stored in Dataverse and do not require rapid scaling. - Exchange server-side sync is not configured. Adopters - Adopter information is stored in a Contact table. - Contacts are considered to be duplicates if they have the same email address and last name. - Adopters are often late to meetings, so a reminder email is sent to them two hours before their meeting. - The email reminders must not be tracked in the system. Dogs - Dog information is stored in a Dog table, which is organization owned. - Breed, size, and weight are fields in the table. Dog residency - A Resident table tracks the stay of each dog. - Each resident record has a lookup for the dog and its food. - The food type and amount are logged on each resident record. Auto-posting is not configured for changes to food type and amount. - A fee of $120 is in a currency column named Adoption Fee. This fee can be changed depending on the adoption circumstances. - A formula column named Deposit is automatically populated with 20% of the adoption fee. - A resident record is generated automatically when a dog record is created. This is the only way a resident record can be created. Exercise and feedings - Exercise for the dogs is tracked in an Exercise table. - Feedings are tracked in a Feeding table. - Exercise and feeding records appear in a resident record timeline. Care staff - The care staff must be able to view who changed the food type and the amount that was given, for up to three months ago. - The staff must be able to update the weight of a dog on the resident record. - The staff report that the buttons are too small on the touch screen they use to log exercise and feeding. - The staff must be able to view who the adopters are for upcoming meetings. The staff must not be able to update adopter information. Administrative staff - Administrative staff must receive a weekly list of duplicate contacts. Duplicate alerts must not appear when a staff member saves a new contact. - When an adopter wants to adopt a dog, the staff must perform a series of adoption duties in order. The following duty list must be displayed on the screen: o Commitment: - Obtain adopter signature in a commitment document. - Collect deposit. o Pre-pickup: - Document spay or neutering date. - Perform spay or neutering. - Document pickup date. o Pickup: - Collect full payment. - Verify dog is picked up. o A dog must be picked up no sooner than two days after spaying or neutering. o A pop-up window must appear with an error message if the Pickup date is too soon. o Only administrative staff must be able to add new adopters and dogs. Drag and Drop Question You need to set up a security role for the care staff. Which privileges should you set? To answer, move the appropriate privileges to the correct create, read, write tables. You may use each create, read, write privileges once, more than once, or not at all. You may need to move the split bar between panes or scroll to view content. Answer:

Exhibit

PL-200 question #332 exhibit

Answer Area

Drag items

None - Organization - NoneOrganization - Organization - NoneNone - Organization - OrganizationNone - Organization - Organization

Correct arrangement

  • None - Organization - None
  • None - Organization - None
  • None - Organization - Organization

Explanation

This question tests understanding of Dataverse security roles, specifically how record ownership (User-owned vs. Organization-owned) and data usage patterns influence the scope of Create, Read, and Write privileges in a single business unit environment, using abstract privilege labels.

Approach. The core of this question lies in interpreting the abstract 'Privileges' options ('ScopeA - ScopeB - ScopeC') and matching them to table requirements, considering Dataverse record ownership and a single business unit environment. The most consistent interpretation, based on the provided solution and Dataverse principles, is that 'ScopeB' always represents 'Organization' scope for Read. 'ScopeA' (Create) and 'ScopeC' (Write) scopes are context-sensitive based on the table's ownership:

  • If a table is User-owned (default for Contact): 'None' in ScopeA/ScopeC implies 'User' scope; 'Organization' implies 'Organization' scope.
  • If a table is Organization-owned: 'None' in ScopeA/ScopeC implicitly means 'Organization' scope (as User scope is not applicable for C/W on Org-owned records), and 'Organization' explicitly means 'Organization' scope.

Applying this interpretation:

  1. Adopters (Contact table): Contacts are typically User-owned by default in Dataverse. Shelter staff need to create new adopter records, all staff need to read all adopter records, and usually, the staff member who created or is assigned to an adopter record manages its updates. This translates to User Create - Organization Read - User Write privileges. This matches the 'None - Organization - None' option (where 'None' implies User scope for Create and Write on a User-owned table).

  2. Dogs (Organization owned): The case explicitly states the 'Dog' table is organization owned. For organization-owned tables, all records are accessible and managed across the entire organization. Therefore, staff need Organization Create - Organization Read - Organization Write privileges for these records. The draggable option selected is 'None - Organization - None'. Under our contextual interpretation, for an organization-owned table, 'None' for Create and Write implicitly means 'Organization' scope. So, this option effectively grants Organization Create, Organization Read, and Organization Write for the Dogs table.

  3. Residents (Tracks dog stay): This table tracks operational data like food type, amount, and adoption fees, which can change and need to be logged or updated by various staff members. This implies a need for shared write access (Organization Write). While a staff member might initiate/create a new resident record (User Create), all staff need to read all records (Organization Read) and update any record (Organization Write). This translates to User Create - Organization Read - Organization Write privileges. This matches the 'None - Organization - Organization' option (where 'None' implies User scope for Create, and 'Organization' explicitly means Organization scope for Write on a User/BU-owned table like Residents).

Common mistakes.

  • common_mistake. A common mistake is a literal interpretation of 'None' in the draggable privilege options as 'no access' for Create or Write at the Organization level. This interpretation would lead to an unusable application for most tables, especially for 'Dogs' which is explicitly organization-owned and requires full management. For example, if 'None - Organization - None' meant 'No Create, Organization Read, No Write', it would contradict the need for staff to create and update records for Adopters and Dogs. Similarly, not recognizing that the 'Residents' table requires organizational-level write access for shared operational updates would lead to incorrect selections like 'Organization - Organization - None' or 'None - Organization - None'.

Concept tested. Dataverse security model, specifically: record ownership types (User-owned, Organization-owned), privilege scopes (User, Business Unit, Organization) for Create, Read, and Write operations, and how these are applied in a single business unit environment, often requiring contextual interpretation of abstract privilege labels.

Community Discussion

No community discussion yet for this question.

Sign up to join the discussion
Full PL-200 Practice