Sharing-and-Visibility-Architect Exam Questions

Explanation: The action that Mary can take on Joe’s Invoice records is none. This is because Mary’s profile does not have the Read permission for the Invoice object, which means she cannot view any Invoice records, regardless of the OWD or role hierarchy settings. Profile permissions override any other access settings3. Read/Write, Edit Only, and View Only are not possible actions for Mary.

Explanation: The most likely cause of this problem is that the sales rep was manually removed from the Opportunity team. This would revoke the access to the opportunity record that the sales rep was helping with. The other options are not valid causes, because:

• The Account team does not affect the Opportunity team members, unless the account owner changes and the opportunity owner is set to match2.
• The Opportunity team is specific to each opportunity record, so removing the sales rep from one opportunity team does not affect the access to another opportunity record of the same account3.
• The opportunity owner cannot enable/disable if the “Default Opportunity team” is able to access the record. The default opportunity team is a template that can be applied when creating or editing an opportunity, but it does not override the existing opportunity team members.

Explanation: A sharing rule is missing to share Accounts to the AR team, which could be the issue preventing AR team members from seeing invoices. Since invoice is a custom object with a master-detail relationship to account, its sharing settings are controlled by its parent account. If AR users do not have access to account records, they will not be able to see or query invoice records either. Option A is incorrect, since a sharing rule to share invoices to the AR team would not work, as invoice inherits its sharing settings from account. Option B is incorrect, since assigning an invoice page layout to the AR team profile would not affect their visibility of invoice records. Option D is incorrect, since giving read permission to the invoice object to the Accounts receivable profile would not grant access to invoice records that are owned by other users.

Explanation: Using bind variables or the escapeSingleQuotes() method are two techniques that can prevent SOQL Injection attacks by ensuring that user input is treated as literal strings rather than part of the query9. Bind variables are preferred over escapeSingleQuotes(), as they also improve performance and readability of the code10. Option A is incorrect, since escaping double quotes in the user input does not prevent SOQL Injection. Option D is incorrect, since using the with Sharing keyword on the controller does not affect SOQL Injection, but rather enforces record-level access based on the user’s profile and sharing rules.

Explanation: The license type that must be used by community users who want to collaborate on opportunities is Partner Community. As mentioned above, Partner Community licenses allow users to access standard CRM objects such as opportunities and collaborate with other partners and internal users using Chatter and Communities. Sales Community licenses do not exist as a separate license type. Customer Community and Customer Community Plus licenses do not allow users to access opportunities, as they are intended for customer service scenarios rather than sales scenarios.

Explanation: The license recommendation that will meet distributor needs is Partner Community. Partner Community licenses are designed for users who are not employees of UC, but are part of their partner ecosystem, such as distributors, resellers, or suppliers. Partner Community users can access standard CRM objects such as accounts, contacts, leads, opportunities, cases, and campaigns. They can also collaborate with other partners and UC employees using Chatter and Communities. Sales Cloud licenses are for internal sales users who need full access to standard CRM and custom objects. Customer Community Plus licenses are for high-volume customers who need access to standard CRM objects and custom objects, but not opportunities. Customer Community licenses are for low-volume customers who need access only to custom objects and a subset of standard CRM objects.

Explanation: The architect can achieve this requirement by using a permission set. A permission set is a collection of settings and permissions that give users access to various tools and functions3. The architect can create a permission set that grants edit access to the flag field on the case object, and assign it to the users who are assigned as case assessors. Object permissions control the access level that users have to records, not fields. A custom lightning component is not necessary for this requirement, as it can be done declaratively. Field-level security controls the visibility of fields on page layouts and reports, not the editability.

Explanation: Creating a Share Group based on the sharing set created for the Customer Community User Profile is the best way to give support representatives access to Container and Case records owned by Customer Community users. Share Groups are groups of users who have access to records based on a sharing set. Sharing sets are settings that grant community users access to records that have a lookup relationship to their user record1. Creating an ownership-based sharing rule, creating a criteria-based sharing rule, and relying on the role hierarchy are not options that can achieve the same result.

Explanation: Assigning users profiles and unlocking users are two capabilities that the delegated administrator permission provides. Delegated administrators are users who can perform certain administrative tasks on behalf of administrators. These tasks include assigning users to specified profiles or permission sets, creating and editing users in specified roles or groups, unlocking users who have exceeded their login attempts limit, resetting passwords for users in specified roles or groups, logging in as users who have granted login access to administrators. Option C is incorrect, since setting OWD is not a capability that delegated administrators have. Option D is incorrect, since creating profiles is not a capability that delegated administrators have.

Explanation: Using the IsUpdateable() Apex method to test each field prior to allowing updates is the best way to fix this problem. This method returns true if the user has permission to edit a specific field on a specific object, and false otherwise. Option A is incorrect, since putting the code in a class that uses the With Sharing keyword would not affect field-level security permissions, but rather record-level access based on sharing rules. Option C is incorrect, since using the with SECURITY_ENFORCED keyword in the SOQL statement would not prevent updates on fields that are read-only for certain profiles, but rather enforce field- and object-level data protection. Option D is incorrect, since adding with Sharing keyword to the class would have the same effect as option A.