Salesforce-Platform-Sharing-and-Visibility-Architect Practice Test Questions

Explanation:

To ensure all internal employees can view ServiceFeedback records while restricting partners, the Organization-Wide Default (OWD) must be configured separately for internal and external users. Since OWD for external users is already Private, setting the OWD for internal users to Public Read-Only is the most scalable solution. This grants all employees read access without manual sharing rules or role hierarchy adjustments.

Why Not A or B?

Option A (Owner-based sharing rule) only shares records owned by partners, leaving other records inaccessible unless manually shared.

Option B (Role Hierarchy) is irrelevant because internal employees don’t need hierarchical relationships to access partner-owned records. Role Hierarchy primarily controls access for records owned by users below in the hierarchy, not lateral or external ownership.

Key Consideration:

Salesforce allows different OWD settings for internal vs. external users via profiles or permission sets. Public Read-Only for internal users ensures compliance while minimizing administrative overhead.

Explanation:

The Partner Super User feature is designed for this exact scenario. It allows designated users (e.g., partner managers or agents) to view records owned by other users within the same account (distributor). This is scalable and requires no manual sharing adjustments.

Why Not A or B?

Option A (Permission set for admin access) grants excessive privileges, risking data exposure.

Option B (Delegate external user) is temporary and impractical for ongoing collaboration.

How It Works:

When enabled, Partner Super Users automatically inherit Read/Edit access to records owned by users under the same account. This aligns with the requirement for agents to view peer cases without custom sharing rules.

Explanation:

In Salesforce, role hierarchy automatically grants record access upward. This means:

➡️ If a record is owned by someone lower in the hierarchy (for example, an operations user), their manager (higher role in the hierarchy) automatically gets access to view and edit those records (assuming OWD isn’t set to “Public Read/Write”).
➡️ Since the operations users report to the operations manager, the manager inherits edit access to their scheduled courses via role hierarchy.

So, the simplest and most scalable solution is to rely on role hierarchy, not on ownership-based sharing rules or public groups.

Why not the other options?

A. Ownership-based sharing rule: Not needed. Sharing rules are for opening access across the hierarchy (e.g., between peers or unrelated roles). In this case, the role hierarchy already covers the manager → subordinate access.

C. Public group: Adding users to a group doesn’t automatically give edit rights. You would still need a sharing rule or manual sharing. Overcomplicates the scenario.

Salesforce Reference:
Role Hierarchy and Record Access
“Users higher in the hierarchy always have access to the records owned by users below them in the hierarchy.”

✅ Final Answer: B

Explanation:

Let’s break it down step by step:

1. What are sharing sets?
Sharing sets are a feature in Salesforce designed for Experience Cloud (formerly Community Cloud) users, like those with Partner Community licenses. They allow you to grant access to records based on the user’s profile or role. In this case, sharing sets can be used to give partner managers access to records owned by other users who share the same account (distributor) in the community.

2. Why is this the best option?
The question asks for a scalable solution. Sharing sets are built for scenarios like this, where you want to grant access to a group of users (like partner managers) for records related to their account (the distributor).
With sharing sets, you can configure access so that all partner managers at a distributor can see all case and container records for partner users tied to the same distributor account. This is done automatically based on the account association, making it efficient and scalable for 200 distributors.
Sharing sets work well with Partner Community users because they respect the account-based structure of partner data.

3. Why not the other options?

A. Create an ownership-based sharing rule.
Ownership-based sharing rules grant access based on who owns the record or the role/profile of the owner. However, in this scenario, the records are owned by partner users at the same distributor, and the partner manager role may not directly tie to ownership. Ownership-based sharing rules are better for internal users, not community users, and would require complex setup to achieve the same result as sharing sets. This makes it less scalable.

B. Give Super User permission to the individual partner manager users.
Super User access (available in some Salesforce editions) allows partner users to view all data for their account, but it’s a permission applied at the user level and isn’t role-based. Assigning Super User permissions to individual partner managers one by one isn’t scalable for 200 distributors, as it would require manual configuration for each user. Also, Super User access might give too much visibility (e.g., to all objects), which may not be desired.

4. How sharing sets work in this case?
You create a sharing set for the partner manager role (or profile) in the Experience Cloud.
You configure the sharing set to grant access to case and container records where the account matches the distributor account of the partner manager.
This ensures that partner managers only see records for their own distributor, keeping data secure from other distributors.

Reference:
Salesforce Help: Sharing Sets for Experience Cloud Users
Salesforce Help: External Sharing Model

Explanation:

This question tests the understanding of how Apex Managed Sharing shares behave during owner changes and the critical role of the RowCause field.

Why C is Correct: When you create an Apex Managed Share, you must specify a RowCause (Reason for Sharing). The key is to use a custom sharing reason (e.g., My_Sharing_Reason__c) instead of the default 'Manual'. Shares with a custom RowCause are persistent and are not automatically removed when the record owner changes. The sharing is tied to the record itself, not the owner. This is the declarative mechanism designed specifically to solve this problem.

Why A is Incorrect: The with sharing keyword is an enforcement of record-level security (CRUD, FLS, and sharing rules) within an Apex class. It controls what records the Apex code itself can see during its execution. It has absolutely no bearing on how shares are stored in the database or their behavior when a record's owner is changed. It is unrelated to the persistence of sharing records.

Why B is Incorrect: Creating a share with the RowCause of 'Manual' is functionally equivalent to a user manually clicking the "Share" button. The critical behavior is that all shares with a RowCause of 'Manual' are automatically deleted by the platform when the record owner changes. This is the exact opposite of the desired outcome and would guarantee the users lose access.

Reference:
Salesforce Help: Apex Managed Sharing - Specifically states: "Sharing records that have a custom row cause are not deleted when the record owner changes. Sharing records that have a row cause of Manual are deleted when the record owner changes."

Platform Sharing and Visibility Architect Exam Guide: This falls under the objective "Given a scenario, design a sharing strategy that uses Apex managed sharing." Understanding the implications of the RowCause field is a fundamental concept for this objective.

Explanation:

The correct answer is C. Public Groups.

Here's why:

🟢 C. Public Groups are the ideal way to group a set of unrelated users, roles, or other public groups to simplify sharing. Once a public group is created, it can be used in a variety of sharing mechanisms, such as manual sharing, sharing rules, and territory management, to grant access to a specific set of records.

🔴 A. Role Hierarchy is used to grant access to records based on a user's role in the organization. Users at a higher level in the hierarchy can automatically see all records owned by users below them, but it doesn't solve the problem of granting access to an unrelated group of users who may not have a hierarchical relationship.

🔴 B. Sharing Sets are used to grant access to records for guest users in a community or portal based on a lookup relationship between the user's community account or contact and the target records. This is a very specific use case and isn't a general solution for sharing with a group of internal users.

In summary, when the goal is to grant access to a collection of users who don't share a common role or hierarchy, Public Groups are the most effective and direct method.

Explanation:

Opportunities are part of Salesforce’s sales objects (along with Leads, Quotes, Campaigns, etc.).
Not all community license types grant access to sales objects.

Here’s the breakdown:
➡️ Customer Community: Designed for high-volume external users (like end customers). Grants access mainly to cases, knowledge, and custom objects. Does not include Opportunities.
➡️ Customer Community Plus: A step up, adds reporting, dashboards, and some sharing features. But still does not allow access to Opportunities or Leads.
➡️ Partner Community: Designed for partners, resellers, and distributors. Grants full access to sales objects, including Opportunities, Leads, Campaigns, and Contacts. ✅
So, if you want community users to work with Opportunities, the license must be Partner Community.

Salesforce Reference:
Experience Cloud User Licenses
Partner Community licenses provide access to sales data such as Opportunities, Leads, and Campaigns.

✅ Final Answer: C. Partner Community

Explanation:

Correct Answer: A, B, and C (All of the above)
All three options highlight important considerations for the development team when implementing a solution with LWC as the view layer and Apex classes for business logic. Let’s go through each one to understand why they matter.

A. Once that Apex runs on system mode, the development team needs to enforce record visibility.
What does this mean?
In Salesforce, Apex classes run in system mode by default, which means they don’t automatically respect the user’s sharing rules or record-level access permissions. This is different from the user interface, where sharing rules (like who can see which records) are enforced automatically. When building custom Apex logic, the development team must manually check if the user has access to the records being queried or modified.

Why is this important?
Since support reps will use the LWC to interact with data, the Apex code needs to ensure that reps only see or edit records they’re allowed to based on Salesforce’s sharing model (e.g., role hierarchy, sharing rules, or manual sharing). If the team doesn’t enforce record visibility, a rep might accidentally see or change data they shouldn’t, which could lead to security issues.

How do they enforce it?
The team can use methods like WITH SECURITY_ENFORCED in SOQL queries or check record access with Schema.sObjectType.

Explanation:

This question tests the understanding of different sharing mechanisms and their resilience to future changes, specifically record ownership reassignment. The key requirements are: sharing an Opportunity, involving specific roles (product specialist, solution engineer), and anticipating a future owner change.

Why C is Correct: Opportunity Teams are the optimal solution for this scenario.
➡️ Persistent Access: When the Opportunity owner changes, all Opportunity Team members and their roles and access levels are automatically retained. The sharing is tied to the record itself, not the original owner.
➡️ Granularity: It allows the junior account manager to grant precise access (e.g., Read/Read-Write) to specific individuals for this specific Opportunity, which is exactly what is needed.
➡️ Best Practice: Using teams (Opportunity Teams, Account Teams, Case Teams) is the Salesforce-recommended best practice for collaborating on specific records with a group of users, as it is designed to be stable through ownership changes.

Why A is Incorrect: A manual share on the opportunity is fragile. Manual shares (those with a RowCause of 'Manual') are automatically deleted when the record owner is changed. The moment the account is reassigned to a senior account manager (which likely also changes the Opportunity owner), the manually shared access for the product specialist and solution engineer would be lost, breaking the collaboration.

Why B is Incorrect: A manual share on the account is also fragile for the same reason as A; it would be deleted on an owner change. Furthermore, it is inefficient and less secure. Sharing the entire account would grant the specialists access to all account data and potentially all its child records (other Opportunities, Contacts, etc.), which violates the principle of least privilege. They only need access to this one specific Opportunity.

Reference:
Salesforce Help: About Opportunity Teams - "Opportunity team members retain their access to the opportunity even if the opportunity owner changes."
Platform Sharing and Visibility Architect Exam Guide: This scenario touches on objectives like "Given a scenario, determine how to use implicit sharing." and designing sharing solutions that are robust against organizational changes. Using teams is a key strategy for this.

Explanation:

This option is the most effective and efficient way to meet all the stated requirements. Let's break down why:

✅ Account Teams: This feature allows users to be added to a team on a specific account and be granted varying levels of access to the account itself, as well as its related Opportunities and Cases. This directly addresses the need for sales associates to have read access to accounts and cases, while also providing a mechanism for selective access to opportunities when required.
✅ Read Access to Accounts and Cases: By adding a sales associate to an Account Team, an administrator can specify "Read Only" access to the account and its related cases. This fulfills requirements 1 and 2.
✅ No Access to Deals (Opportunities): The Account Team functionality allows for granular control over access to related records. An architect can set the sales associate's Opportunity access to "Private" or "No Access" within the Account Team settings. This directly satisfies requirement 3. When an associate needs access to an opportunity, they can be added to the opportunity team on a case-by-case basis.

🔴 Why other options are incorrect:

❌ B. Use Account teams and Case teams: No configuration required for the Opportunity object: This is an inefficient approach. While Account Teams can handle account and opportunity sharing, Case Teams would be a separate, additional layer of complexity that isn't necessary. Account Teams can already provide access to related cases.

❌ C. Use Account teams and sharing rules to share cases with sales associates: No change required to the Opportunity object: Sharing rules are not granular enough to handle the specific, per-account requirements described. They typically share records based on criteria (e.g., owner, field value) and would be a static, organization-wide setting rather than a dynamic, per-account solution for defining user roles. This would be a less flexible and more complex solution than simply using the built-in functionality of Account Teams.