Salesforce has a built-in sharing behavior known as implicit sharing. When a user is granted access to a child record, such as an Opportunity, Case, or Order, they automatically receive implicit, read-only access to the parent Account record. In this scenario, giving the finance analyst access to the Opportunity record triggered this child-to-parent implicit share, granting her access to the associated Account. The subsequent access to Contact records is a consequence of this Account access, assuming the Contact's organization-wide default is 'Controlled by Parent'.

B. Account records can be accessed due to Role Hierarchy.

Role hierarchy provides vertical access based on a user's position in the hierarchy, not access to a specific, individual record.

C. Contact records can be accessed due to implicit sharing from Opportunity.

This is an indirect effect. The primary implicit share is from the Opportunity to the parent Account. Access to Contacts is a result of gaining access to the Account.

---

1. Salesforce Help, "Implicit Sharing":

"If you have access to a child record, such as an opportunity, case, or order, you have implicit Read-Only access to the parent account." This directly confirms that access to an Opportunity grants access to the parent Account.

2. Salesforce Architect's Guide, "Record-Level Security":

Under the section for Implicit Sharing, the guide explains that access to child records like opportunities provides implicit read-only access to the parent account. This is a fundamental, non-configurable behavior of the platform.

3. Salesforce Help, "Organization-Wide Sharing Defaults":

This document explains the 'Controlled by Parent' setting for Contacts. It states, "A user can perform an action (such as view, edit, or delete) on a contact based on whether they can perform that same action on the associated account." This clarifies why access to the Account (from the Opportunity) subsequently grants access to the Contacts.

The requirement is to grant a few specific users read-only access to all Opportunity records, overriding the private organization-wide default. The most precise and secure method to achieve this is by using a permission set. The "View All" permission is an object-level permission that grants read access to all records of a specific object (in this case, Opportunity), irrespective of sharing rules or ownership. This adheres to the principle of least privilege by not granting unnecessary access to other objects or system-wide data modification capabilities. Assigning this permission via a permission set allows for targeted access for only the required users.

A. View All Data is a system-level permission that grants read access to all data in the org, which is overly permissive and violates the principle of least privilege.

B. While using a permission set is correct, granting View All Data is still too broad, as it provides access to all objects, not just the required Opportunity object.

1. Salesforce Help & Training, Object Permissions: This document distinguishes between object-level permissions. It states, "For each object, View All and Modify All...give users access to all records of that object, regardless of sharing settings." This directly supports using "View All" for the Opportunity object.

Reference: Salesforce Help, "Object Permissions," under the "Standard Object Permissions" section.

2. Salesforce Help & Training, Permission Sets: This resource explains the purpose of permission sets. "A permission set is a collection of settings and permissions that gives users access to various tools and functions...you can use permission sets to grant access to custom objects or to make a field visible or editable in a specific app." This supports using a permission set for a small group of users.

Reference: Salesforce Help, "Permission Sets," "Permission Set Concepts" section.

3. Salesforce Architects, Record-Level Security: The Architect's guide on sharing discusses how permissions can override sharing. It clarifies the difference between object-level permissions like "View All" and system-wide permissions like "View All Data," recommending the former for object-specific requirements.

Reference: Salesforce Architect's Handbook, "Record-Level Security," section on "Object Access via Profiles and Permission Sets."

4. Salesforce Help & Training, Administrative Permissions: This document details system-wide permissions. It describes "View All Data" as a permission that allows a user to "View all data for your organization, regardless of the user's permissions." This confirms that options A and B are too broad for the stated requirement.

Reference: Salesforce Help, "Administrative Permissions," entry for "View All Data."

Account Teams are the ideal solution as they are designed to grant a team of users record-level access to a specific Account and its related child records. By configuring an Account Team, an architect can define specific roles for each member (e.g., "Sales Associate") and precisely control their access levels for the Account, as well as its related Opportunities and Cases. To meet the requirements, the Sales Associate role on the Account Team would be configured with Read-Only access to Accounts, Read-Only access to Cases, and Private (no access) to Opportunities, all within a single feature.

B. Use Account teams and Case teams. No configuration required for the Opportunity object.

Case Teams grant access to a single Case, not all Cases related to an Account. Account Teams can already provide the required Case access, making Case Teams redundant and incorrect for this scenario.

C. Use Account teams and sharing rules to share cases with sales associates. No change required to the Opportunity object.

Sharing rules are criteria-based and grant broad access, which is not suitable for the requirement of granting access to specific users on specific accounts. Account Teams provide the necessary record-by-record access control.

1. Salesforce Help, "Account Teams": "An account team is a team of users who work together on an account... You can specify each team member’s role... and level of access to the account and its contacts, opportunities, and cases." This document confirms that Account Teams are the single feature designed to manage access to an account and its related standard objects.

2. Salesforce Help, "Set Up Account Teams": Under the section for setting up teams, the documentation details the ability to define team member access levels for Account, Contact, Opportunity, and Case. The available access levels for Opportunities and Cases are "Private," "Read-Only," or "Read/Write," directly enabling the solution described.

3. Salesforce Architects, "Record-Level Sharing: Under the Hood" (White Paper): This document explains various sharing mechanisms. It positions teams (Account, Opportunity) as a method for flexible, user-managed sharing on a record-by-record basis, contrasting them with the automated, criteria-based nature of Sharing Rules. This supports why Account Teams are appropriate and Sharing Rules are not.

This requirement calls for a horizontal data segregation model based on record criteria (geographic location). The standard and most effective Salesforce pattern to achieve this is a two-step process. First, establish the most restrictive baseline access by setting the Organization-Wide Defaults (OWD) for the Account object to 'Private'. This ensures users can only see records they own by default. Second, create criteria-based sharing rules to grant wider access. These rules will share Account records where the geographic location field matches the branch's location with the corresponding group of users (e.g., a public group for that branch).

A. Configure Role Hierarchy and create sharing rules.

This is incomplete. It omits the critical first step of setting the OWD to Private. Without a restrictive OWD, users might already see all records, making the sharing rules ineffective for restricting access.

B. Create the Account Team and add branch manager team members, and configure organization-wide defaults of the Account object.

Account Teams are designed for sharing individual records for collaboration, not for systematically sharing all records in a geographic area. This approach is not scalable and is the wrong tool for this requirement.

1. Salesforce Architects - Record-Level Security: In the "Record-Level Security (Who Sees What)" guide, the process is explicitly outlined: "Use organization-wide defaults to lock down your data to the most restrictive level, and then use the other record-level security tools to grant access to other users selectively." This directly supports setting OWD first, then using tools like sharing rules.

2. Salesforce Help - Organization-Wide Sharing Defaults: "Organization-wide sharing settings specify the default level of access that users have to each other’s records... For the most restrictive access, set the default to Private." This confirms that setting the OWD to Private is the foundational step for restricting visibility.

3. Salesforce Help - Sharing Rules: "Sharing rules give particular users greater access by making automatic exceptions to your organization-wide sharing settings." This documentation clarifies that sharing rules are used to open up access from the OWD baseline, which is precisely what is needed after setting the OWD to Private.

4. Salesforce Trailhead - Control Access to Records: The "Define Sharing Rules" unit states, "Sharing rules represent the exceptions to your organization-wide default settings... you can use sharing rules to grant them access to records they don’t own." This reinforces the relationship where OWDs restrict and sharing rules grant exceptions.

The primary issue is the manual effort sales reps expend to grant access to a consistent group of supporting users for their accounts. Default Account Teams are designed specifically to automate this process. Each sales rep can pre-define their standard team of collaborators (legal, engineering, etc.) in their personal settings. When that rep creates a new account or becomes the owner of an existing one, their default team is automatically added to the Account Team. This grants the necessary record-level access to the support staff without requiring manual sharing for each record, directly improving the sales reps' productivity.

A. Create a criteria based sharing rule to grant access to other users.

This is incorrect because criteria-based sharing is driven by record attributes, not by the user who owns the record. It cannot dynamically build a team specific to each sales rep.

C. Create a permission set with View All Data and assign to supporting users.

This violates the principle of least privilege. "View All Data" grants access to all customer records, not just the specific ones where support is needed, creating a significant security risk.

---

1. Salesforce Help, "Set Up a Default Account Team": "To save time and for consistency, you can set up a default account team of colleagues you typically work with on your accounts... When you create or own an account, your default team is automatically added to the account team." This directly supports the automation and productivity goal.

2. Salesforce Help, "Account Teams": "An account team is a team of users who work together on an account... An account team can include an executive sponsor, a dedicated support representative, and a project manager, for example." This confirms the feature's purpose is to manage access for collaborative teams like the one described.

3. Salesforce Security Guide, "Object-Level Security" (Page 10): The guide details administrative permissions like "View All" and "Modify All". It explains that these permissions override sharing rules and settings, granting access to all records of a specific object. This confirms that using "View All Data" (Option C) is an inappropriate and overly permissive solution for record-specific access.

4. Salesforce Architect's Handbook, "Record-Level Security": This resource often contrasts sharing mechanisms. It would position Account Teams as the appropriate solution for stable, user-centric, collaborative teams, whereas criteria-based sharing rules (Option A) are for broad, automated sharing based on record data, not team composition.