Examkin

Question

Difficulty: Very hardRole Hierarchy and Sharing Rules

A company uses a custom object named `Project_Audit__c` with Organization-Wide Defaults (OWD) set to Private. To prevent executive roles from automatically inheriting record access, the System Administrator deselects the Grant Access Using Hierarchies checkbox on the `Project_Audit__c` object definition.

The administrator must configure record access to fulfill two specific business requirements:
1. Users assigned to the Audit Lead role must be able to view and edit all `Project_Audit__c` records owned by users in the Audit Analyst role.
2. Users in the Compliance Team public group must receive Read-Only access to any `Project_Audit__c` record where the `Risk_Level__c` picklist field is set to 'High'.

Which TWO configuration steps should the administrator perform to meet these requirements? (Select 2 answers)

  1. Create an owner-based sharing rule on Project_Audit__c that shares records owned by members of the Audit Analyst role with the Audit Lead role, granting Read/Write access.Answer
  2. Create a criteria-based sharing rule on Project_Audit__c where Risk_Level__c equals 'High', sharing records with the Compliance Team public group with Read-Only access.Answer
  3. C
    Re-enable Grant Access Using Hierarchies on Project_Audit__c and restrict executive access using Profile object permissions.
  4. D
    Create a Permission Set granting 'Modify All Data' and assign it to users in the Audit Lead role and Compliance Team public group.
  5. E
    Set the Organization-Wide Default (OWD) for Project_Audit__c to Public Read-Only and create restriction rules for non-compliance users.

Answer

The administrator must create an owner-based sharing rule to share records owned by the Audit Analyst role with the Audit Lead role with Read/Write access, and create a criteria-based sharing rule to share records matching Risk_Level__c = 'High' with the Compliance Team public group with Read-Only access.
When 'Grant Access Using Hierarchies' is unchecked for a custom object, higher-level roles no longer inherit record access automatically. To restore access for managers over subordinate records without re-enabling global hierarchy access, an owner-based sharing rule must be configured between the respective roles. Additionally, granting access based on a field attribute (such as Risk_Level__c = 'High') requires a criteria-based sharing rule targeted to the specified public group.

Step-by-Step Solution

1
Analyze the impact of disabling Grant Access Using Hierarchies on custom objects.
Disabling 'Grant Access Using Hierarchies' on a custom object prevents users higher in the role hierarchy from automatically inheriting record access to records owned by or shared with their subordinates.
When standard hierarchy access is disabled, explicit sharing mechanisms must be defined for manager roles to gain access to subordinate records.
2
Address Requirement 1 (Audit Leads accessing Audit Analyst records).
Create an Owner-Based Sharing Rule on `Project_Audit__c`. Set the owned-by group to 'Role: Audit Analyst' and share with 'Role: Audit Lead' with Read/Write access.
Owner-based sharing rules can explicitly target source roles and share access with target roles when hierarchy inheritance is turned off.
3
Address Requirement 2 (Compliance Team accessing High Risk records).
Create a Criteria-Based Sharing Rule on `Project_Audit__c`. Set criteria to `Risk_Level__c EQUALS High` and share with 'Public Group: Compliance Team' with Read-Only access.
Criteria-based sharing rules evaluate record field values and share matching records with designated user groups regardless of who owns the records.

Key Concept

Role Hierarchy Custom Object Access Toggles and Sharing Rule Selection
Rate this question

Topics

Role Hierarchy and Sharing Rules

More questions from this topic