A sharing set is the optimal and standard feature designed specifically for granting high-volume community users access to records associated with their account or contact. For users with a Customer Community license, a sharing set can be configured to grant access to Case records where the Case.AccountId matches the User.Contact.AccountId. This is a declarative, scalable, and purpose-built solution that directly fulfills the requirement without the need for custom code or complex rule administration, making it the most efficient and maintainable option.

A. Use Apex sharing to share cases with the students.

Apex sharing is a programmatic solution for complex scenarios. It is not optimal when a standard declarative feature like a sharing set directly addresses the requirement.

B. Create a sharing rule to share cases with the students.

Sharing rules grant access to roles, territories, or public groups. Customer Community users do not have roles, and this mechanism cannot dynamically grant access based on the user's specific account.

1. Salesforce Help, "Set Up a Sharing Set": This document explicitly states, "Sharing sets grant site users access to records that are associated with their accounts or contacts." It details the process of creating an access mapping, such as User.Contact.AccountId = Case.AccountId, which is the exact solution needed for the scenario.

2. Salesforce Architects, "A Guide to Sharing Architecture" (PDF): In the section "Sharing with External Users" (page 31), this guide describes sharing sets as the primary mechanism for sharing records with high-volume community users. It states, "Sharing sets are the preferred way to share records with external users who have Customer Community, Customer Community Plus, and Partner Community licenses."

3. Salesforce Help, "Experience Cloud User Licenses": This documentation clarifies the capabilities of different community licenses. For the Customer Community license, it notes that these users do not have roles in the Salesforce role hierarchy, which invalidates the use of role-based sharing rules for this license type.

The scenario describes a classic case of Field-Level Security (FLS) settings. While the sales users have object and record-level access (allowing them to find and open the Invoice record), their profile lacks the necessary "Read" permissions for the specific fields on that object. FLS governs the visibility and editability of individual fields for different user profiles. The System Administrator profile typically has permissions like "View All Data" and full FLS, which is why they can see all the fields, whereas the Sales User profile has not been granted the same level of access.

A. A role-based sharing rule is missing and should be added for the sales user's role to grant access to the fields.

Sharing rules are used to grant users access to records they do not own, not to control the visibility of specific fields within those records.

C. The page layout assigned to Sales User profile has only Read-Only access to the fields.

If the fields were set to "Read-Only" on the page layout, the user would still see the fields and their data but would be unable to edit them. The issue described is that the fields are not visible at all.

---

1. Salesforce Help, "What Determines Field Access?": This document explicitly states that field accessibility is determined by a combination of settings, primarily Field-Level Security and page layouts. It clarifies, "You can control users’ access to fields at the record type, user, or field level... Field-level security settings can restrict users’ access to fields." This directly supports that a user's profile (FLS) is the primary control for field visibility.

2. Salesforce Help, "Set Field-Level Security for a Single Field on All Profiles": This guide details the process for controlling field access. It notes, "Field-level security lets you restrict what fields users can view and edit based on their profiles." This confirms that the profile is the mechanism for controlling field visibility, as stated in the correct answer.

3. Salesforce Help, "Sharing Rules": This official documentation defines sharing rules as a mechanism to "extend sharing access to users in public groups, roles, or territories." This confirms that sharing rules operate at the record level, not the field level, making option A incorrect.

4. Salesforce Help, "Page Layouts": The documentation explains, "Page layouts control the layout and organization of... fields... on object record pages." It also clarifies that while a field can be marked as read-only on a page layout, this is distinct from it being hidden entirely due to FLS. This supports the reasoning for why option C is incorrect.

The optimal solution is to clone the existing Sales Rep profile. This new, cloned profile can then be modified to grant access to the new application's components (e.g., objects, tabs, Visualforce pages) while simultaneously revoking access to the legacy functionality. Assigning this new profile to the small set of pilot users ensures they have the correct permissions without impacting the majority of sales reps who remain on the original profile. This approach correctly uses profiles to define a user's baseline access, which includes both granting and restricting permissions.

B. Revoke access to legacy functions in the Sales Rep profile and create a permission set for the new functionality.

This is incorrect because modifying the base Sales Rep profile would revoke legacy access for all sales reps, not just the pilot group, disrupting business operations.

C. Create a permission set to grant access to the new functionality and hide the old functionality.

This is incorrect because permission sets are additive; they can only grant permissions, not revoke or hide access that is already granted by a user's base profile.

---

1. Salesforce Help Documentation - "Profiles":

Content: "Profiles define how users access objects and data, and what they can do within the application... A profile is a collection of settings and permissions that determine what users can see... and what they can do."

Reference: Salesforce Help, Article "Profiles". This establishes that a profile is the correct tool for defining a user's fundamental access, which includes what they can and cannot see/do.

2. Salesforce Help Documentation - "Permission Sets":

Content: "A permission set is a collection of settings and permissions that give users access to various tools and functions... Permission sets extend users’ functional access without changing their profiles."

Reference: Salesforce Help, Article "Permission Sets". This source confirms that permission sets are for extending or granting additional access, not for revoking permissions already granted by the profile, which is a key requirement of the scenario.

3. Trailhead - "Data Security" Module, "Control Access to Objects" Unit:

Content: "The principle of least privilege states that you should only give users the access they need to do their jobs... While both profiles and permission sets are used to configure a user’s permissions, they serve different purposes... A user can have only one profile, but they can have multiple permission sets. When a user’s permissions are determined, Salesforce takes the union of all permissions from the user’s profile and any assigned permission sets."

Reference: Trailhead, Data Security Module. This reinforces that permissions are cumulative and that a permission set cannot override a profile to remove access. To create a different baseline of access (adding new and removing old), a different profile is required.

The most optimal and scalable solution is to use the Partner Role Hierarchy. When a partner account (the dealership) is enabled for community access, Salesforce automatically creates a dedicated, three-level role hierarchy for that account: Partner User, Partner Manager, and Partner Executive. By assigning the service agents to the Partner User role and their dealer manager to the Partner Manager role within the same dealership account, the standard role hierarchy sharing mechanism grants the manager visibility into all records, including cases, owned by their subordinate service agents. This approach requires no custom sharing rules and scales automatically as new dealerships are added.

Why Incorrect Options are Wrong

B. Create a sharing rule to share cases created by service agents with their dealer manager.

This is not optimal because it would require creating and maintaining a separate sharing rule and corresponding public groups for each of the thousands of dealerships, leading to significant administrative overhead and potential performance issues.

C. Create a sharing group to share cases created by service agents with their dealer manager.

Share Groups are used to share records owned by internal Salesforce users with external community users, or records owned by high-volume community users. They do not facilitate sharing between standard partner community users based on a managerial relationship.

References

1. Salesforce Help, "Partner Role Hierarchy": "When you enable the first external user on a partner account, a user role hierarchy is created for that account... The partner roles are created in a three-level hierarchy: Partner User, Partner Manager, and Partner Executive... Having a role hierarchy for your partners means that... partner managers can see all the data of partner users." This directly confirms that the role hierarchy provides the required visibility.

2. Salesforce Architects, "Record-Level Security": The guide explains that the first line of defense for vertical data access is the Role Hierarchy. It states, "The role hierarchy enables users above another user in the hierarchy to have all the privileges of the user below them... This is the standard behavior and cannot be changed." This principle applies to both internal and partner role hierarchies.

3. Salesforce Help, "Share Records Using Share Groups": "A share group allows you to share records owned by Salesforce users in a share group with external site users." This documentation clarifies that Share Groups are for sharing from internal to external users, not between external users in a hierarchy, making option C incorrect.

When implementing a complex, custom sharing solution like Apex managed sharing, testing is critical to ensure the logic correctly grants or revokes access for different users. The runAs(user) system method in an Apex test class allows the test to execute from the perspective of a specific user. This enables developers to create test scenarios that verify whether a user with a certain profile or role can access a record after the sharing logic has been executed, confirming the implementation meets the requirements. This is a fundamental best practice for validating record visibility rules.

A. Use "Without Sharing” keyword to make sure record visibility will be considered.

This is incorrect. The without sharing keyword causes Apex code to run in system context, explicitly ignoring the running user's record-level sharing settings.

B. Use "With Sharing” keyword to enforce Field-Level Security.

This is incorrect. The with sharing keyword enforces the running user's record-level sharing, but Field-Level Security (FLS) is always enforced in Apex regardless of the sharing keyword.

1. Apex Developer Guide, "runAs Method": "The runAs method enables you to write test methods that change the user context to an existing user or a new user so that the user’s record sharing is enforced. You can use runAs only in test methods. The original system context is resumed after all runAs code completes." This directly supports using runAs to test record sharing.

2. Apex Developer Guide, "Using the with sharing, without sharing, and inherited sharing Keywords": "Use the without sharing keyword when you want to ensure that the Apex code runs in system context and has access to all records... Field-level security is always enforced regardless of the sharing keywords." This confirms that option A's reasoning is backward and option B's link between with sharing and FLS is false.

3. Salesforce Architects, "Record-Level Security": In the section on programmatic sharing, the guide implicitly requires robust testing for such custom solutions. Testing with runAs is the standard mechanism to validate that the programmatic sharing correctly enforces the intended access controls for various user personas.

Apex classes, when invoked from a Lightning Web Component, run in system mode but default to a without sharing context. This means that by default, they do not enforce the running user's record-level sharing settings, potentially exposing data the user should not see. Therefore, a primary consideration for the development team is to explicitly enforce record visibility. This is achieved by declaring the Apex class with the with sharing or inherited sharing keyword, which ensures that all SOQL queries and DML operations respect the user's sharing rules and permissions.

B. Create test classes including runAs to test different users accessing the data.

This is a best practice for validating the sharing implementation, not the primary implementation consideration itself. The core task is to first write the code to enforce sharing (Option A).

C. Use isSharesble, isEditable, and isCreatable to enforce field permissions.

This option lists incorrect method names (isUpdateable, not isEditable) and misapplies isShareable. These methods check Field-Level Security (FLS) and object properties, not enforce record-level visibility.

1. Salesforce Apex Developer Guide, "Using the with sharing, without sharing, and inherited sharing Keywords":

"An Apex class with the @AuraEnabled annotation that is called from a Lightning component (Aura or LWC) defaults to without sharing." This statement confirms that developers must take explicit action to enforce sharing for LWC controllers.

2. Salesforce Secure Coding Guide, "Enforcing Sharing Rules":

"By default, Apex code runs in system context... The only exceptions to this rule are Apex code that is executed with the executeAnonymous call and Chatter in Apex. To enforce sharing rules, you must declare the class with the with sharing keyword." This highlights the developer's responsibility to enforce sharing.

3. Salesforce Apex Developer Guide, "Enforcing Object and Field Permissions":

This section details the use of Schema Describe methods like isAccessible(), isCreateable(), and isUpdateable() to verify a user's access to objects and fields (FLS), which is distinct from the record-level sharing enforced by the with sharing keyword. This clarifies the inaccuracy of option C.

4. Salesforce Apex Developer Guide, "Testing with runAs":

"The runAs method enables you to write test methods that change the user context to an existing user or a new user so that the user’s record sharing is enforced." This confirms that runAs is a testing tool used to verify sharing behavior.

Field-Level Security (FLS) is the primary Salesforce mechanism for controlling user access to specific fields. By setting the Date of Birth field to 'Visible' for the Customer Support Rep profile, they are granted both read and edit permissions. For the Banking Rep profile, setting the field to 'Visible' and 'Read-Only' ensures they can view the data, which makes it searchable, but prevents them from making any edits. This method is the most direct and secure way to meet the requirements, as FLS is enforced across the entire platform, including the user interface, reports, and API.

A. Validation rules are for enforcing data integrity, not controlling field access. This approach provides a poor user experience by blocking edits only upon save and does not control searchability.

C. Search layouts determine which fields appear in search results, not whether a field is searchable. Page layouts are a less secure control for editability than FLS.

1. Salesforce Help, "Field-Level Security": "You can restrict users’ access to fields by setting field-level security... For example, you can make a field visible and read only for a certain profile." This document explicitly describes the functionality used in the correct answer.

2. Salesforce Help, "Control Access to Fields": "After you set object-level permissions... you can set permissions for fields... Field-level security settings let you restrict what fields users can view and edit based on their profile..." This confirms that FLS is the designated tool for controlling view and edit permissions on a per-profile basis.

3. Salesforce Security Guide, "Data Security" chapter, "Field-Level Security" section (page 18): "Field-level security—or field permissions—control whether a user can see, edit, and delete the value for a particular field on an object... Field permissions are also controlled in permission sets and profiles." This guide establishes FLS as the fundamental layer for column-level security.

4. Salesforce Help, "Searchable Fields by Object in Lightning Experience": This documentation implicitly supports the answer by showing that for a field to be searchable, a user must have at least read access to it, which is granted by setting FLS to 'Visible'.

This scenario requires a dynamic sharing solution where the recipient of the share (the manager) is determined by a user lookup field on the record itself (the agent of the complaint). Standard declarative sharing rules cannot accommodate this logic, as they share with predefined roles or groups, not with a user identified through a field on the record. Apex Managed Sharing is the appropriate tool for this requirement. A trigger on the Case object can identify the agent, find their manager via the ManagerId field on the User object, and then programmatically insert a CaseShare record to grant the manager specific access.

B. Criteria based Sharing Rule on Case that shares to the Role Manager and above when a custom field Assigned Agent (subject of the complaint) is not blank.

A criteria-based sharing rule cannot dynamically share a record with the specific manager of a user listed in a lookup field; it can only share with predefined roles or groups.

C. Case is owned by the subject of the complaint, so their manager in the role hierarchy can access the record. CRED permission are removed on Case so the agent cannot read the case record.

A record owner always has full access (Read, Edit, Delete) to their own records, regardless of object-level permissions on their profile. It is impossible to prevent an owner from reading their record.

1. Salesforce Apex Developer Guide, "Sharing a Record Using Apex": This guide explicitly states, "Use Apex managed sharing if... The sharing requirements are based on the record’s data... For example, a custom object has a lookup field to a user, and that user must have access to the record." This directly matches the scenario.

2. Salesforce Security Guide, "Data Access and Security": This document details the different levels of data access. It confirms that record owners have implicit full access. Under the "Record-Level Access" section, it clarifies that ownership grants View, Edit, Transfer, and Delete permissions, which cannot be revoked by object permissions.

3. Salesforce Help, "Create a Sharing Rule": The documentation for creating sharing rules shows that the "Share with" options are limited to Public Groups, Roles, Roles and Subordinates, and Territories. There is no option to select a user based on a lookup field from the record being shared.

4. Salesforce Architects, "Record-Level Access: Under the Hood" Whitepaper: This paper discusses the different sharing mechanisms. In the section on Programmatic Sharing, it highlights its use for complex sharing rules that cannot be implemented declaratively, such as when access is granted to users referenced in lookup fields on a record. (See Figure 5: Sharing Mechanisms and Common Use Cases).

With the Organization-Wide Default (OWD) for Accounts set to Private, access to records not owned by a user must be explicitly granted. A criteria-based sharing rule is the appropriate mechanism to grant access to a specific subset of records based on their field values. In this scenario, a rule can be configured using the IsPersonAccount field (IsPersonAccount = TRUE) to identify all retail customers. This rule would then share these specific Account records with users in the "Retail Sales" role, fulfilling the requirement to grant them access to all Person Accounts while excluding Business Accounts. The "2" in the option is likely a typo; a single rule is sufficient.

B. Create an owner-based sharing rule on AccountContactRelation...

This is incorrect because it shares records from the AccountContactRelation junction object, not the Account object itself, and thus would not grant visibility to the required Account records.

C. Update the Retail Sales profile to grant access to Person Account record type.

This is incorrect because record type access on a profile controls a user's ability to create records of that type and which page layout to use; it does not grant visibility to existing records they do not own.

1. Salesforce Help, "Criteria-Based Sharing Rules": "Criteria-based sharing rules determine who to share records with based on field values... For example, you can create a rule that shares all open cases with a high priority with a specific public group." This directly supports using criteria (e.g., IsPersonAccount = TRUE) to share records.

2. Salesforce Object Reference Guide, "Account": The guide details the IsPersonAccount field, a read-only Boolean field that is true if the account is a person account. This field is the ideal criterion for the sharing rule.

3. Salesforce Security Guide, "Controlling Access Using the Role Hierarchy": This guide explains the layers of data access. It clarifies that after OWDs, "You can use sharing rules to grant additional access to users." It also implicitly distinguishes this from profile-level settings, which control object and field-level security, not record-level access for records owned by others. (See the "Summary of Data Access" diagram).

When the organization-wide default is Private, access must be explicitly granted. A criteria-based sharing rule is the most appropriate mechanism to grant access to a specific subset of records, in this case, "high-value opportunities." Since the auditors are distributed throughout the organization and do not share a common role, a public group is the correct construct to group these users together. The sharing rule can then grant access to all records meeting the "high-value" criteria to the public group containing the auditors. This solution is precise, scalable, and adheres to the principle of least privilege.

B. Add the auditors to the default Opportunity Team.

This grants access to all new opportunities created by a user, not just the "high-value" ones, and does not grant access to existing records.

C. Put the auditors at the highest level of the Role Hierarchy.

This would grant excessive access to all opportunities and potentially other records owned by users below them, violating the principle of least privilege.

---

1. Salesforce Help Documentation, "Create Sharing Rules": This document details the process and use cases for sharing rules. It states, "You can create rules to grant wider access to data for particular groups of users... A criteria-based sharing rule determines with whom to share records based on field values." This directly supports using criteria (e.g., Amount > X) to share records with a specific group.

Source: Salesforce Help, "Create Sharing Rules," Section: "Criteria-Based Sharing Rules."

2. Salesforce Help Documentation, "Manage Public Groups": This resource explains the function of public groups. It notes, "Public groups are a way to group users... regardless of their role or territory assignment." This confirms that a public group is the correct tool for grouping the "distributed" auditors who do not share a common role.

Source: Salesforce Help, "Public Groups," Section: "Set Up Public Groups."

3. Salesforce Architect's Guide, "Record-Level Security": This guide compares different sharing mechanisms. It positions sharing rules as the primary tool for opening up access horizontally and conditionally when the role hierarchy is insufficient. It states, "Use sharing rules to grant record access to users in public groups, roles, or territories... when you need to grant access based on a record’s field values."

Source: Salesforce Architects, "Architect's Guide to Record-Level Security," Section: "Declarative Sharing."

4. Salesforce Help Documentation, "Controlling Access Using Hierarchies": This document explains the limitations of the role hierarchy for this scenario. It clarifies that the hierarchy grants vertical access to all records owned by subordinates, which is too broad for the requirement of accessing only "high-value" opportunities.

Source: Salesforce Help, "Controlling Access Using Hierarchies."