Salesforce-Platform-Sharing-and-Visibility-Architect Practice Test
Updated On 18-Sep-2025
77 Questions
Universal Containers (UC) has affiliates who sell containers in countries where UC does
not have a local office. UC uses a Partner Community to manage thesales cycle in those
countries. One of its affiliates has grown substantially and restructured its internal sales
team with the following structure: Sales VP —> Directorof Sales —> Sales Manager —>Sales Reps. Sales Reps should not see each others’opportunities, and visibility of deals
should open up within a Sales Rep's hierarchy.
What is the main problem an architect should address in this situation?
A. The Channel Manager role cannot be shared with Partner Community.
B. Partner User roles arelimited to three Ievels.
C. Partner Community does not support Role Hierarchy.
Explanation:
Partner Community licenses restrict partner user role hierarchies to a maximum of three levels beneath the Channel Manager role. UC’s affiliate has four levels (VP → Director → Manager → Rep), but only three can be represented. The architect must address this structural mismatch, either by consolidating levels (e.g., combining Director and Manager) or by using Sharing Sets/Security Groups for finer control.
→ It’s not that the Channel Manager role can’t be shared (A), nor that Partner Communities lack hierarchy entirely (C).
→ The core limitation is the three-level cap, which directly prevents modeling the full affiliate structure in the partner role hierarchy.
To grant Universal Containers sales managers access to shipment records properly, it was
necessary to leverage Apex managed sharing. The IT team is worriedabout improper
access to records.
What should an architect recommend to mitigate this risk?
A. Use isSharesble keyword in Apex classes to assure record visibility will be followed.
B. Use runAs system method in test classes to test using different users and profiles.
C. Use isAccesible keyword in Apex classes to assure record visibility will be followed.
Explanation:
When leveraging Apex Managed Sharing, it’s critical to test that the correct users get or don’t get access. The System.runAs() method allows you to execute test code under the context of different users (with varying roles, profiles, and sharing). By writing tests that runAs(distributorUser) or runAs(salesManager), you can assert that sharing entries created by your Apex logic yield the expected visibility.
→ with sharing or isShareable (A, C) control runtime sharing behavior but don’t verify it.
→ Only runAs lets you simulate and validate access in unit tests, giving confidence that your managed sharing rules won’t over-expose or under-expose records.
Universal Containers (UC) is in a legal dispute regarding several orders. UC has found out
these records were removed from the system. The VP of Sales has asked to ensure this
cannot happen in the future.
Which approach should meet this requirement?
A. Change the Record Type/Page Layout assignment for Orders to be Read-Only.
B. Remove the Delete button from the Order Page Layout.
C. Remove Order Delete permission from profiles and permission sets.
Explanation:
To prevent deletions at scale, you must remove the core Delete object permission. Simply hiding the Delete button on a page layout (B) doesn’t stop API or inline deletion. Changing record types or layouts to Read-Only (A) doesn’t influence permissions; users with Delete permission could still remove records if they find another route. By revoking Delete in profiles/permission sets, you ensure no user can delete Order records, period, regardless of UI.
A sales coach at Universal Containers wants to create and share a report folder with other
sales coaches.
Which two permissions are required to accomplish this?
A. Create Report Folders and manage Reports in Public Folders
B. Create and customize Reports and Report Folders
C. Manage Reports in Public Folders and edit My Reports
Explanation:
To create a new report folder, a user must have the “Create Report Folders” permission. To share and manage the contents of a public folder, they need “Manage Reports in Public Folders.” Together, these provide end-to-end control: the ability to spin up folders and then set sharing, move reports in and out, and manage access.
→ “Create and Customize Reports” (B) is for building report definitions, not folder creation.
→ “Edit My Reports” (C) only touches personal reports or existing folder content; it doesn’t let you create folders or govern sharing at the folder level.
Universal Containers has expanded to sell virtual containers for data storage. Virtual
container work orders are provisionedimmediately by the system andtherefore cannot be
changed by a sales rep.
What is an optimal approach to implement these requirements?
A. Implement a sharingrule that changes access for all Work Orders to Read.
B. Change the Record Type/Page Layout assignment for Work Orders to Read Only.
C. Remove the Work Order Edit permission from the Sales Representative profile.
Explanation:
When a process auto-provisions work orders, the business rule is that no sales rep should ever alter them. The simplest, most robust enforcement is to strip Edit rights at the profile level. Removing the “Edit” permission for Work Orders prevents any UI, API, or integration from updating them under that profile.
→ A sharing rule (A) only controls record-level sharing, not edit capability.
→ Changing record types or layouts (B) can hide fields but doesn’t prevent DML via API or other interfaces.
By removing the core object permission, you guarantee work orders remain immutable by sales reps in all contexts.
| Page 1 out of 16 Pages |