Salesforce Plat-Arch-205 - Salesforce Certified Platform Sharing and Visibility Architect

Salesforce can make a custom list view visible to a role and its internal subordinates, which is appropriate when the intended audience already aligns with the role hierarchy. Using that audience avoids maintaining dozens of list views against individual users and allows the hierarchy to represent the geographic or organizational population naturally. A queue is intended for supported record ownership and workload distribution, not for governing list-view visibility. Direct sharing to arbitrary individual users is also not the standard list-view model; when the population does not correspond to a role, a public group is typically the better abstraction. The architect must distinguish list-view visibility from record visibility: being able to select a view does not grant access to the Opportunities that satisfy its filter. Each user still sees only records allowed by object permissions, OWD, hierarchy, sharing rules, teams, and other record-level mechanisms. Study Guide reference: Access to Other Data - list views, roles and internal subordinates, public groups, scalable view administration, and separation of view access from record access.

The Presenters junction object expresses a dynamic user-to-record relationship: each Presentation has a different set of users who must be able to edit it, and that set can change over time. Apex-managed sharing is appropriate because a trigger on the junction object can create a share when a presenter is added and remove that access when the relationship is deleted or changed. The Presentation object ' s OWD can remain Private while only the users represented by the junction records receive the necessary Edit access. A permission set cannot grant access to one specific Presentation record; it supplies object, field, or system permissions and must be combined with a record-level sharing mechanism. Standard Sales Team functionality also does not apply to an arbitrary Presentation custom object. For a robust custom-object design, the implementation should use a dedicated Apex Sharing Reason so the programmatic shares are easy to distinguish and manage throughout the record lifecycle. Study Guide reference: Access to Records - Apex-managed sharing, junction objects, dynamic user-to-record relationships, custom sharing reasons, and Private OWD.

Granular Locking is the platform capability associated with reducing group-membership lock contention during large changes to roles, groups, territories, and related sharing structures. A major role hierarchy realignment can cause many concurrent operations to update group membership and sharing tables. Without sufficiently granular locking, unrelated changes can be serialized behind broad locks, increasing the probability of contention and long-running maintenance operations. Granular locking narrows the scope of locks so unrelated hierarchy branches and group structures can be processed more independently where the relationships allow it. Divisions serve a different purpose: they partition data for organizational and reporting needs but do not solve group-membership locking during hierarchy maintenance. Skinny tables are database-performance optimizations and are unrelated to access recalculation. For enterprise-scale realignments, architects should also plan maintenance windows carefully and avoid overlapping major sharing, territory, role, and user-provisioning operations. Study Guide reference: Implications of Security Model Choice - enterprise-scale sharing, role hierarchy maintenance, group-membership locking, granular locking, and access-model performance.

Dynamic Forms is the most maintainable solution for an object with hundreds of fields and several distinct business processes. It allows the Lightning record page to be decomposed into individual fields and field sections, then uses visibility rules to show only the information relevant to the current Work Order or Case type. Record Type can be used as the controlling condition so one governed Lightning page supports multiple process variants without multiplying page layouts or introducing custom LWC code. A custom override with metadata would create unnecessary development and maintenance overhead for behavior the platform can provide declaratively. Separate page layouts per type can work, but with hundreds of fields they become harder to govern and often duplicate large portions of configuration. Dynamic Forms is therefore the declarative-first architecture. The architect must still enforce sensitive-data restrictions through Field-Level Security because conditional page visibility is not an authorization control. Study Guide reference: Implications of Security Model Choice - Dynamic Forms, Record Types, field sections, component visibility, large-field-count page design, and UI visibility versus FLS.

Deferred Sharing Calculation is intended for major administrative changes that would otherwise cause Salesforce to repeatedly recalculate sharing while the organization is still in an intermediate state. During a large role hierarchy restructuring and mass Account ownership realignment, each individual change can affect group membership and record access. With deferred calculation enabled, administrators can suspend automatic calculation while they perform the planned restructuring and then explicitly resume and recalculate after the final model is in place. This reduces repeated work and can materially improve the operational stability of a very large reorganization. The capability must be governed carefully because access changes made while calculation is suspended are not reflected until the recalculation is completed. Skinny tables solve a different database-performance problem, and Divisions partition data but do not prevent repeated sharing recalculations. Study Guide reference: Implications of Security Model Choice - Deferred Sharing Calculation, large organizational changes, role and ownership maintenance, sharing recalculation, and operational governance.

The Partner Community role hierarchy naturally models the relationship between service agents and their dealer manager. Agents can occupy a lower partner role and the dealer manager a higher role within the same partner account, allowing record visibility to roll upward while users at the same lower level remain isolated from one another under a Private sharing model. This is more efficient than creating a separate sharing rule for every dealer-manager relationship because the management structure itself already expresses who should inherit access. A sharing group is associated with other Experience Cloud access patterns and does not replace the partner role hierarchy for this requirement. The architect should ensure that the partner roles are correctly assigned and that the underlying Case object permissions support the access the manager needs. Study Guide reference: Access to Records - Partner Community roles, external role hierarchy, Private Case sharing, manager access, and scalable Experience Cloud design.

Super User access is designed for selected external partner managers who need visibility across records associated with other users at the same partner account. Granting that elevated access to the individual partner manager is more scalable than creating and maintaining separate ownership-based sharing rules for every distributor. The requirement is deliberately limited to certain managers, so the organization can keep the external sharing model private between distributors while giving designated managers broader visibility within their own distributor organization. Sharing Sets are best suited to deterministic Account/Contact relationship mappings and do not replace the manager-level elevation represented by the Super User model. Because Super User access is powerful, it should be assigned only to users who genuinely need it and should be reviewed as part of the external-access governance process. Study Guide reference: Access to Records - Partner Community, Super User access, partner manager visibility, same-account external sharing, distributor isolation, and scalable Experience Cloud access.

Shipment is a custom object, so Salesforce allows the administrator to control whether access automatically rolls upward through the role hierarchy. If Grant Access Using Hierarchies is disabled, a correctly configured manager role does not by itself provide access to Shipment records owned by subordinate users. With a Private OWD, this produces exactly the symptom described: managers cannot see their team ' s records even though the hierarchy is otherwise correct. Re-enabling Grant Access Using Hierarchies restores the normal upward inheritance pattern for the custom object, assuming managers also have the required object-level permissions. An ownership-based sharing rule is not required merely to reproduce ordinary manager-to-subordinate access, and there is no separate generic switch called ' Role Hierarchy implicit sharing ' that replaces this custom-object setting. Study Guide reference: Access to Records - custom-object OWD, Grant Access Using Hierarchies, role hierarchy, inherited access, and Private sharing. The implementation should also be validated with representative users so effective permissions, sharing inheritance, and any cross-object access behave exactly as designed before production release.

The record must be shared with a dynamically determined user: the manager of the person identified on the Case. A criteria-based sharing rule can evaluate Case fields, but its recipient is a fixed role, group, or other supported target; it cannot resolve a different manager for every record and share only to that person. Programmatic sharing is therefore the appropriate pattern. A trigger can inspect the Legal SME or complaint-agent field, determine the required manager or specialist, create the corresponding Case share, and remove or replace that share when the relationship changes. Making the subject of the complaint the owner would expose the sensitive Case to exactly the person who must not see it, while removing Case object permission from the entire support-agent population would be far broader than required. The design should keep the Case baseline restrictive and grant access only to the HR owner plus the dynamically determined authorized user. Study Guide reference: Access to Records - programmatic Case sharing, dynamic recipients, user lookup relationships, sensitive-record isolation, and least privilege.

The requirement is an authorization requirement, not merely a page-design preference. Removing the Work Order Edit object permission from the Sales Representative permission model prevents those users from updating Work Orders regardless of which UI, API, automation entry point, or page layout they use. Page layouts can make fields appear read-only, but they are presentation controls and should not be relied on as the security boundary. A sharing rule is also the wrong tool because sharing rules add record-level access; they do not reduce the CRUD capabilities a user already has. In a modern Salesforce permission architecture, the organization should remove Edit from the relevant profile or baseline permission set and verify that no other assigned permission set or permission set group grants it back, because permissions are additive. The page can still be configured to present an appropriate read-only experience, but enforcement belongs at the object-permission layer. Study Guide reference: Permissions to Standard Objects, Custom Objects, and Fields - object CRUD, profiles, permission sets, page-layout limitations, and least-privilege authorization.