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

View All Records is an object-specific sharing override. Granting View All on Case lets the service representative see every Case regardless of the Case OWD, but it does not automatically grant the same access to Account or other related standard objects. Each object still requires its own object permission and record-access path. This is an important distinction from normal implicit sharing: Salesforce does not treat a broad View All grant on the child object as though the user had individually received each child record through ownership or a normal share, so the expected parent access must be evaluated separately. If Contact is Controlled by Parent, Contact visibility depends on the user ' s access to the parent Account. The architect must therefore design Account access explicitly rather than assuming that universal Case visibility cascades through the customer data model. Study Guide reference: Access to Records - View All Records, object-specific sharing overrides, Account/Case relationships, Controlled by Parent, and Private OWD.

The field is unavailable because an encrypted field cannot be used directly as the criterion in a criteria-based sharing rule. This is a platform limitation arising from the security properties of encrypted data, not a consequence of the architect ' s personal Field-Level Security. Granting the administrator more visibility to the field therefore would not make the field eligible for sharing-rule criteria. The design implication is important: encryption can affect downstream functionality such as filtering, searching, deterministic comparisons, reporting, and sharing-rule logic. If UC needs sharing behavior related to the sensitive Social Security Number, the architect should avoid duplicating the plaintext value merely to bypass the restriction. A safer design is to use a non-sensitive classification, segment, status, or derived security indicator that expresses the business condition without exposing the protected identifier. The encryption decision and the sharing design must therefore be considered together rather than independently. Study Guide reference: Implications of Security Model Choice - Shield Platform Encryption limitations, criteria-based sharing, sensitive-data architecture, and security design trade-offs.

External organization-wide defaults are designed for this exact separation of internal and external access. UC can keep the internal default for ServiceFeedback at the level required by employees while setting Default External Access to Private for authenticated external users. That creates a restrictive baseline for partner users without reducing internal visibility. Sharing rules are additive: they can open access beyond the organization-wide default, but they cannot take away access already granted by a public OWD. For that reason, neither an owner-based nor a criteria-based rule can be used to make external access more restrictive. After the external OWD is Private, UC can selectively grant the required records through the appropriate Experience Cloud mechanism, such as sharing sets, partner roles, sharing rules, or other supported sharing constructs depending on the relationship model. This follows the least-privilege design principle used throughout Salesforce security architecture: establish the most restrictive baseline that satisfies the broad population, then add narrowly scoped exceptions. Study Guide reference: Access to Records - organization-wide defaults, external OWDs, Experience Cloud record access, sharing rules, and least-privilege sharing.

Custom Apex that serves a Lightning component must not assume that the client-side component has already enforced the user ' s data access. Apex can execute in system context, so the development team must explicitly preserve record visibility and enforce the user ' s CRUD and Field-Level Security where appropriate. The record-level requirement can be handled with the correct sharing declaration or user-mode operations, while object and field authorization can be enforced through user mode, Security.stripInaccessible(), or valid Schema Describe checks. Creating runAs tests is valuable for verification but does not secure production execution. Likewise, method names such as isShareable are not valid substitutes for the platform ' s real security APIs. The architectural principle is to treat the LWC-to-Apex boundary as a server-side trust boundary: every Apex entry point should return only records and fields that the running user is entitled to access. Study Guide reference: Permissions to Standard Objects, Custom Objects, and Fields - system-mode Apex, record-sharing enforcement, CRUD/FLS, user-mode operations, and Lightning/Apex security boundaries.

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.

A Sharing Set is designed for Experience Cloud users whose record access can be derived from the Account or Contact relationship associated with their external user. In this scenario, all users at a distributor share the distributor-account context, and Delivery records can be related to the customers assigned to that distributor. A Sharing Set can map the external user ' s Account or Contact relationship to the corresponding relationship on the target object and grant the required Read Only or Read/Write access when the values match. This scales much better than creating separate public groups and sharing rules for hundreds of distributors. It also keeps the access relationship data-driven, so membership changes follow the user ' s account relationship instead of requiring manual maintenance of sharing artifacts. The architect must ensure that the selected external license supports the required object and sharing-set configuration and that the target relationship is eligible for the mapping. Study Guide reference: Access to Records - Experience Cloud sharing, Sharing Sets, account/contact access mappings, distributor isolation, and scalable external record access.

Mary has no effective access because object-level Read permission is a prerequisite for every record-level access mechanism. Public Read-Only OWD and the role hierarchy can determine which Invoice records a user may see only after the user is authorized to read the Invoice object itself. Mary ' s profile does not grant that permission, so neither the public OWD nor her position above Joe can make Joe ' s Invoice records available. Record sharing never substitutes for object CRUD. This is a core Salesforce security-order concept: object permissions establish whether a user can use an object, Field-Level Security determines which fields are available, and OWD, hierarchy, sharing rules, teams, and manual sharing determine which records are visible. Granting Read through a profile or permission set would be required before Public Read-Only or hierarchy-derived access could take effect. Study Guide reference: Permissions to Standard Objects, Custom Objects, and Fields - object CRUD, profiles, permission sets, OWD interaction, role hierarchy, and layered security evaluation.

A Salesforce File posted to a record inherits visibility from the record context according to the file-sharing configuration. The file owner retains access, and users who can access the associated record can generally access the file at the level permitted by the file ' s visibility settings. The object ' s Private OWD therefore matters because only users who obtain access to the specific record through ownership, hierarchy, teams, sharing rules, or another valid mechanism fall within the record audience. A shared Chatter post link does not by itself bypass the underlying record and file security model. Architects should treat file security as a related but distinct layer: the ContentDocument and ContentDocumentLink model determines where a file is shared, while record access and file visibility determine who can actually open it. Study Guide reference: Access to Other Data - Salesforce Files, record-associated file visibility, Chatter feeds, ContentDocument access, and record 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.

A public group is the scalable audience mechanism for list views that should be visible only to a defined set of users. UC can create groups that represent the relevant geography or specialist population and share each list view with the appropriate group instead of trying to maintain visibility user by user. This becomes especially important when there are dozens of list views and frequent personnel changes: administrators update group membership rather than modifying many view definitions. A queue is intended for supported record ownership and workload distribution, not for controlling list-view visibility. Direct sharing to arbitrary individual users is also not the standard list-view model; a public group provides the reusable abstraction when the target audience does not correspond to a single role. The architect must also distinguish visibility of the list-view definition from visibility of the underlying Opportunity records. Sharing a list view does not grant record access; users still see only records permitted by their object permissions, OWD, hierarchy, sharing rules, teams, and other record-level mechanisms. Study Guide reference: Access to Other Data - list-view sharing, public groups, scalable audience management, and separation of view visibility from record access.

Dynamic Forms is the declarative solution for adapting record presentation without replacing the standard Salesforce page with custom Visualforce or Lightning code. It allows administrators to place fields and field sections individually on a Lightning record page and apply visibility rules based on record context or supported device conditions. That is a better fit for form-factor and alignment problems than maintaining custom view-action overrides that detect devices and route users to different layouts. The declarative approach reduces code ownership, regression risk, testing effort, and long-term maintenance while preserving the standard Salesforce record experience. Where the requirement is driven by record type, the same mechanism can show different field sections for different business processes. The architect must still remember that Dynamic Forms controls presentation rather than security: fields that are hidden by component visibility can still be available through reports, list views, APIs, or other interfaces if Field-Level Security grants access. Sensitive information therefore still requires proper FLS. Study Guide reference: Implications of Security Model Choice - Dynamic Forms, Lightning App Builder, component visibility, record types, device form factors, maintainability, and UI visibility versus security.

The requirement follows a direct manager-to-subordinate relationship, so the role hierarchy is the native record-access mechanism. By placing the operations users below the operations manager and enabling Grant Access Using Hierarchies for the custom Scheduled Course object, Salesforce can automatically provide the manager access to records owned by those subordinate users. The manager must also have the necessary object-level Edit permission because hierarchy access cannot create object capability that the user lacks. A public group alone does not share records; it is simply a reusable collection that must be referenced by another sharing mechanism. An ownership-based sharing rule could create access, but it would duplicate a relationship already expressed by the hierarchy and add unnecessary maintenance across hundreds of regions. Study Guide reference: Access to Records - Role Hierarchy, Grant Access Using Hierarchies, custom-object sharing, manager access, and object permissions. 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.

Among the supplied choices, cloning the Sales Rep profile is the only option that can both grant the pilot functionality and remove legacy functionality for only the selected users. Salesforce permissions are additive: a normal permission set can grant more access, but it cannot negate an existing permission already supplied by the user ' s profile or another permission set. Option B would revoke legacy access from the shared Sales Rep profile and therefore affect the entire sales population, not just the pilot. Option C can add access to the new application, but a standalone permission set cannot hide functionality that the users already receive elsewhere. In a modern design, permission set groups with muting can provide a more composable persona model, but that architecture is not one of the available choices. For the stated options, the separate profile gives the pilot population an independently controlled baseline. Study Guide reference: Permissions to Standard Objects, Custom Objects, and Fields - profiles, permission sets, additive permissions, pilot access strategies, and permission-set-group concepts.

For custom objects, Salesforce allows the administrator to disable automatic upward access through the role hierarchy by clearing Grant Access Using Hierarchies. With the NPS object ' s OWD set to Private and hierarchy access disabled, a manager does not gain access simply because the manager occupies a role above the record owner. This is the correct pattern for sensitive employee information when the reporting hierarchy itself must not imply visibility. Apex sharing should not be used to subtract access that is granted by another mechanism; Salesforce sharing is fundamentally additive. Removing all object permissions from managers would be too broad because it would block every NPS record, including records a manager might legitimately need through another explicit authorization process. The secure design establishes a restrictive baseline and then opens only the records that a specific business requirement justifies. Study Guide reference: Access to Records - Private OWD, Grant Access Using Hierarchies, custom-object hierarchy behavior, sensitive-record isolation, and least-privilege sharing.

This is an ownership data skew problem. Salesforce sharing performance degrades when a single user or queue owns an excessively large number of records of the same object because ownership is deeply involved in sharing calculations, role changes, group membership evaluation, transfers, and other access operations. A common design guideline is to avoid concentrating more than roughly ten thousand records of one object under a single owner when possible. Here, each donations representative owns more than fifty thousand donor Accounts, well beyond that threshold, and the organization has more than twenty million members overall. The problem is therefore structural, not simply a one-time recalculation event or an incorrect permission assignment. The architect should distribute ownership more evenly and, where concentration cannot be avoided, keep heavily skewed owners out of unnecessary roles and groups to reduce sharing complexity. Study Guide reference: Implications of Security Model Choice - ownership data skew, enterprise-scale sharing, Account ownership, role/group participation, and sharing performance.

A public group provides the appropriate reusable population for auditors who are distributed across the organization but share the same record-visibility requirement. UC can maintain the auditors in one group and use an appropriate sharing rule to grant that group access to the qualifying high-value Opportunities. Placing auditors at the top of the role hierarchy would distort the hierarchy ' s business meaning and could expose many unrelated records because hierarchy access is broader than the audit requirement. Adding auditors to every salesperson ' s default Opportunity Team would also be operationally cumbersome and semantically wrong: Opportunity Teams represent collaboration on specific deals, not an enterprise audit function. The public-group pattern separates organizational position from the functional access requirement and makes membership easy to maintain as auditors join or leave the team. With a Private Opportunity OWD, the group should receive only the records needed for the audit process. Study Guide reference: Access to Records - public groups, criteria-based sharing, Private OWD, cross-functional access, and least-privilege audit design.

A criteria-based sharing rule combined with a public group precisely matches the requirement. The records are selected by a business characteristic - whether an Opportunity is high value - while the recipients are a cross-functional set of auditors who do not belong to one common role. The public group provides a stable audience that can be maintained independently, and the criteria-based rule automatically exposes only the Opportunities that meet the defined condition. Placing the auditors at the top of the role hierarchy would grant much broader access and distort the hierarchy ' s organizational purpose. Default Opportunity Teams are tied to deal collaboration and individual owners, so they are not an appropriate enterprise audit mechanism. Starting from a Private OWD and opening only the qualifying records to the auditor group preserves least privilege. Study Guide reference: Access to Records - criteria-based sharing, public groups, Private OWD, cross-functional audit access, and least privilege.

A Public Group is the standard reusable container for users who need common record access but do not share a natural position in the role hierarchy. Public groups can include individual users, roles, roles with subordinates, and other groups, then be referenced by sharing rules or manual sharing. The role hierarchy is intended for vertical access based on organizational responsibility, so forcing unrelated users into one role would distort the security model. Sharing Sets serve a different purpose: they are relationship-based Experience Cloud mechanisms that map an external user ' s Account or Contact relationship to target records. For unrelated internal users, the architect should create a public group and then use that group as the recipient in the appropriate sharing mechanism. This centralizes membership management and lets the record-sharing rule remain stable even as individual users change. Study Guide reference: Access to Records - Public Groups, sharing-rule recipients, cross-functional access, role hierarchy, and scalable record-sharing design.

The custom Apex layer is responsible for enforcing Salesforce security; the Lightning component does not automatically make server-side data access safe. The valid runtime control among the choices is the Apex security mechanism that checks or enforces the user ' s access before data is returned or changed. Field-Level Security must be respected for sensitive values such as Shipment Amount, and the record-sharing model must also be enforced so a Private OWD is not bypassed. Schema Describe checks such as isAccessible(), isCreateable(), and isUpdateable() can be used for explicit field and object permission checks. Current secure-Apex patterns also include user-mode database operations and Security.stripInaccessible(), which can enforce or sanitize CRUD/FLS more comprehensively. Record visibility is a separate layer and should be preserved with the appropriate sharing context. System.runAs() is a testing facility, not a production authorization mechanism, and isShareable is not a valid Apex security keyword. Study Guide reference: Permissions to Standard Objects, Custom Objects, and Fields - secure Apex, CRUD/FLS, record-sharing enforcement, user-mode operations, and Lightning/Apex security boundaries.

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.

A Sharing Set is the standard declarative mechanism for Customer Community users whose Case access can be derived from their Account or Contact relationship. The user ' s external identity is linked to a Contact and therefore to an Account; the Sharing Set can map that user relationship to the Account relationship on Case and grant access when they match. This is especially appropriate for high-volume external users because it avoids building a conventional role hierarchy merely to express simple account-based access. A normal sharing rule is not the best fit for that license model, and Apex sharing would add code and maintenance even though Salesforce already provides a native relationship-based mechanism. The architect should configure the Sharing Set for the applicable external profile, include Case as the target object, select the appropriate access mapping, and grant only the level of access required. Study Guide reference: Access to Records - Customer Community security, Sharing Sets, high-volume external users, account/contact mappings, and Case access.

When a sharing rule grants Opportunity access to members of a public group, the effective audience can also include managers above those group members through the role hierarchy. Salesforce can propagate access upward according to the group ' s Grant Access Using Hierarchies behavior and the object ' s normal hierarchy semantics. That is why the sales engineers in the public group and their managers can have access to the shared Opportunities. The reverse is not true: subordinates of a manager do not inherit records merely because the manager or another subordinate has access, and peer users in comparable roles do not automatically receive one another ' s shared records. Architects must account for this upward propagation when designing public groups for sensitive records because the effective audience may be broader than the explicit list of group members. Study Guide reference: Access to Records - Public Groups, sharing rules, Grant Access Using Hierarchies, upward access inheritance, and Private Opportunity OWD.

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.