Salesforce-Platform-Sharing-and-Visibility-Architect Practice Test Questions (2026)

Summary:
The requirement is to grant granular, record-specific Edit access to a private custom object based on a many-to-many relationship defined in a junction object. The solution must dynamically grant access when a user is added as a presenter and revoke it when they are removed. This requires a programmatic solution that can create and delete sharing records in response to changes in the junction object.

Correct Option:

C. Trigger on Presenter junction object that uses Apex Managed sharing to add or remove access to the related Presentation record.
This is the correct and most robust solution. An Apex trigger on the Presenter__c junction object can fire after insert and after delete. When a new junction record is created, the trigger can create an Apex Managed Share (Presentation__Share) granting the specified user Read/Edit access to the related Presentation__c record. When the junction record is deleted, the trigger can find and delete the corresponding share, dynamically managing access.

Incorrect Options:

A. Give Edit rights to the Presentation record via a Permission set that is given to the Presenters for a record.
This is incorrect and not scalable. Permission sets grant object-level or org-wide permissions, not record-level access. You cannot use a permission set to grant a user Edit rights to one specific Presentation__c record without granting them access to all records or using a different mechanism for the record access itself.

B. Trigger on Presenter junction object that adds the user to the Sales Team for the Presentation record.
This is incorrect because "Sales Team" is specific to the Opportunity object. For a custom object like Presentation__c, there is no standard "Team" feature. The equivalent functionality for a custom object is achieved through Apex Managed Sharing, as described in option C.

Reference:
Salesforce Help: Apex Managed Sharing

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.

Summary:
This question focuses on controlling which users can add products from a specific price book to opportunities. The requirement is to restrict the "High Risk" price book to a select group of trained staff. The solution involves a two-step process: first, restrict access for everyone at the organizational level, and then grant access specifically to the authorized group. Price book sharing is a specific function with its own settings.

Correct Option:

C. Set the price book organization-wide default (OWD) to View Only and share the price book (High Risk) with the trained staff.
This is the correct and complete answer. Setting the Price Book OWD to "View Only" prevents all users from adding products from any price book to an opportunity. The second, critical step is to explicitly share the specific "High Risk" price book with the public group or role containing the trained staff and grant them "Read/Write" or "Use" access, which overrides the OWD and allows them to add its products.

Incorrect Options:

A. Set the price book OWD to View Only and share the (High Risk) price book with the trained staff via manual sharing.
This is incorrect because manual sharing is for individual records, not for price books. Price books are shared through their own dedicated sharing settings, not through the manual share button on a record. This method is not possible or practical for a group of users.

B. Set the price book OWD to View Only and share the (High Risk) price book with the trained staff via a sharing rule. This is incorrect because there are no sharing rules for price books. Standard sharing rules are available for core objects like Accounts and Opportunities, but price book access is managed through its own specific OWD and manual user/group assignment interface, not through criteria-based or owner-based sharing rules.

Reference:
Salesforce Help: Control Access to Price Books

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.

Summary:
The core issue is that a single, rigid page layout does not render optimally across the diverse range of devices (phones, tablets, desktops) used by the sales team. The solution must be a native, declarative, and sustainable way to manage the presentation of fields on an Opportunity record that automatically adapts to different screen sizes and form factors without requiring code or multiple layouts.

Correct Option:

C. Use Dynamic Form to define different field sections applicable for different form factors of devices.
This is the recommended and modern Salesforce solution. Dynamic Forms allows an administrator to create a single Lightning Record Page and use visibility rules to control which fields and sections are displayed based on the user's device (Phone, Desktop, etc.). This ensures an optimal, uncluttered view on any screen, directly solving the alignment and usability problem.

Incorrect Options:

A. Use a custom LWC override for Opportunity view action, identify form factor onLoad action and display relevant layouts based on form factors.
While technically possible, this is a complex, custom-coded solution. It requires development effort, testing, and long-term maintenance. It is not the recommended approach when a robust, native, and declarative tool like Dynamic Forms exists to solve the problem directly.

B. Use a visualforce override for Opportunity view action, identify the form factor onLoad action and display relevant layouts based on form factors.
This is an outdated and overly complex approach. Visualforce is a legacy technology, and using it to override standard view actions is not a best practice in the Lightning Experience. Like option A, it introduces unnecessary code and maintenance where a declarative solution is available.

Reference:
Salesforce Help: Dynamic Forms

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

Summary:
The issue is that a specific field (Social Security Number) is unavailable for selection when defining a criteria-based sharing rule. Sharing rules rely on field values to filter records, but certain field types and configurations are restricted from being used in this context for security and performance reasons. The most common restriction applies to fields containing highly sensitive, personally identifiable information (PII).

Correct Option:

A. The field has been configured for encryption.
This is the most likely cause. Fields encrypted with Shield Platform Encryption are often restricted from being used in certain features, including criteria-based sharing rules, to prevent the encrypted data from being exposed in the underlying sharing queries and to maintain a higher security posture. This is a standard limitation to protect sensitive data.

Incorrect Options:

B. The architect's profile does not have Field Level Security for this field.
While this could prevent the architect from seeing the field's value on a page layout, it does not prevent the field from appearing in the picklist for building a sharing rule in Setup. The sharing rule definition interface in Setup typically shows all fields on the object, independent of the admin's personal FLS.

C. The architect does not have permission to Compliance fields.
"Compliance fields" is not a standard Salesforce term or permission. There is no specific permission that governs access to fields for the purpose of building sharing rules. The restriction is typically applied at the system level based on the field's data type or configuration, such as encryption.

Reference:
Salesforce Help: Shield Platform Encryption Considerations for Sharing Rules

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.

Summary:
The requirement is to restrict the visibility of a specific field (VIP Flag) on the Contact object to only users with the "Private Banking Rep" profile. This is a classic field-level security (FLS) requirement. The solution must control whether the field is rendered on the page at all for a given user, which is a function of the user's profile and permission sets, not the page layout.

Correct Option:

C. Set the Field Level Security for the VIP Flag field so that it is visible to Private Banking Rep Profile.
This is the correct and foundational approach. Field-Level Security in the profile is the primary gatekeeper that determines if a field is visible, readable, or editable. By setting the FLS for the VIP Flag field to "Visible" only for the Private Banking Rep profile and "Not Visible" for all other profiles, the field will be hidden from users who should not see it, regardless of the page layout they are assigned.

Incorrect Options:

A. Change the type of VIP Flag field to a picklist, define a new record type for the Contact Object and make the picklist field available for Editing.
This is an overly complex and incorrect solution. Record types control which fields are available on a page layout for a specific category of records, not which users can see a field. A user with a profile that has FLS access to the field could still see it on a different record's layout or via the API. It does not securely hide the field based on user role.

B. Define a page layout for Contact Object and add the VIP Flag field for that layout.
Remove the VIP Flag field from other layouts. This is insecure and incorrect. Page layouts only organize fields that a user already has permission to see via their profile. If a user's profile has FLS granting them visibility to the VIP Flag field, they can still access it via reports, the API, or by switching to a different layout (if available), making this an unreliable method for enforcing security.

Reference:
Salesforce Help: Field-Level Security