Sharing-and-Visibility-Architect Exam Questions

Explanation: To make the sensitive fields accessible to the Human Resource team, other than field level security, another option is to create a new custom object with private OWD and Lookup relationship to Employee to store new restricted information. This will allow creating a separate security model for the new custom object, which can be shared with the Human Resource team using sharing rules or permission sets. Creating a new custom object controlled by parent and a Master-Detail relationship to Employee will not work, as it will inherit the same OWD as Employee, which is Public Read Only. Changing OWD of Employee custom object to private and a Lookup self-relationship to store only new restricted information will not work, as it will make all employee records inaccessible to other users who need them.

Explanation: Sharing the list views with the appropriate public group and sharing the list views with the appropriate role in the role hierarchy are two ways that UC can hide lists that are not relevant to an individual user. List view sharing allows users to share list views with other users based on public groups, roles, subordinates, or individual users. This way, users can only see list views that are relevant to them and their work. Option A is incorrect, since sharing list views with a queue is not possible. Option B is incorrect, since sharing list views with individual users would be tedious and inefficient.

Explanation: The architect should consider that changing complex role hierarchy can cause a high level of sharing recalculation, and that replacing account records ownerships massively can cause data skew. Changing role hierarchy affects the sharing rules that are based on roles or role and subordinates, which can trigger a recalculation of sharing for all the records owned by users in those roles. Replacing account records ownerships massively can cause data skew, which is a condition where a large number of child records are associated with one parent record, resulting in performance issues. Using a temporary parking lot account to improve performance is not a recommended practice, as it can cause data quality issues and security risks. Restricting the organization-sharing configurations to private is not relevant to this situation, as it does not address the impact of changing roles and reassigning accounts.

Explanation: The OWD for pricebook should be set to Use, which means that users can only view and use price books that are shared with them. This way, sales agents can have access to products and create opportunities for their customers. Option A is incorrect, since Public Read Only would give access to all price books to all users. Option B is incorrect, since Public Read Write would give access and edit rights to all price books to all users. Option C is incorrect, since View is not a valid OWD setting for pricebook.

Explanation: The side effect of this approach is that sales reps on the same team will have read access to the accounts for opportunities owned by their team members. This is because owner-based sharing rules grant access to both the parent and child records of the same object. For example, if a sharing rule grants access to opportunities owned by a certain role, it also grants access to the accounts associated with those opportunities. All sales reps will not have read access to accounts for all opportunities, as the sharing rules are based on ownership. Sales reps on the same team will not have edit access to the accounts for opportunities owned by their team members, as owner-based sharing rules only grant read or read/write access to child records, not parent records. All sales reps will not have read access to all accounts, as the account organization-wide default is private.

Explanation: Setting the case organization-wide default to Private and adding the specialized marketing consultants to the account team with Read/Edit permission are the best recommendations to allow this scenario. This way, only the support rep who owns the case and the marketing consultants who are related to the account can see and edit the case records of VIP customers. Option B is incorrect, since setting the case organization wide default to Public Read Only would give access to all cases to all users. Option C is incorrect, since using a role hierarchy and a read-only ownership-based sharing rule would not give edit access to the marketing consultants. Option D is incorrect, since adding the marketing consultants to the case team would require manual configuration and maintenance.

Explanation: The Grant Access Using Hierarchies option on Shipment Sharing Settings allows users above the owner in the role hierarchy to have the same level of access as the owner. If this option is disabled, the role hierarchy will not grant access to the Shipment records, even if it is configured correctly. Therefore, the answer A is correct and the other options are incorrect

Explanation: The likely cause of this issue is that sales users profile does not have access to the remaining fields. Profile permissions determine what users can do with records, such as create, read, edit, or delete. If sales users profile does not have read permission for certain fields on the Invoice object, they will not be able to see those fields on the record detail page3. Page layout assigned to sales user profile, org-wide sharing settings, and role-based sharing are not likely causes of this issue.

Explanation: Lead and Case are two objects that support creating queues. Queues are used to route records to a group of users who share workloads. Queues are available for standard objects such as Lead and Case, and custom objects that have a queue-supported lookup field. Option A is incorrect, since Account does not support creating queues. Option B is incorrect, since Opportunity does not support creating queues.

Explanation: To give users in the partner user role access to all Case and Container records owned by any user at the same distributor, an Architect can give super user permission to the individual partner users. Super user permission allows partner users to access data owned by other partner users belonging to the same account or below them in the role hierarchy. Creating an ownership-based sharing rule will not work, as it will share records based on the owner’s role or territory, not their account. Creating sharing sets will not work, as they are only available for Customer Community licenses, not Partner Community licenses. Creating a Permission Set granting “View All” permission to Case and Container records will not work, as it will give access to all records in those objects, regardless of their owner or account.