Pass the Salesforce Architect Exams Plat-Arch-205 Questions and answers with CertsForce

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.

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.

Salesforce provides parent implicit sharing for several standard Account relationships. When a user has access to an Opportunity, Case, or Contact, Salesforce can grant Read Only access to the related parent Account so the user can understand the business context of the child record. In this scenario, the sales representative owns the Opportunities, so the representative has direct access to those records and receives implicit Read access to the parent Account even though the Account OWD is Private. That implicit access does not grant Account edit rights. Create/Edit permission on Opportunity determines what the user can do to Opportunity records; it does not translate into Create or Edit access on Account. Object permissions and record access must still be evaluated independently. This behavior is native to standard relationships and should not be confused with a manually created sharing rule. The important exam distinction is that child-record access can produce limited parent visibility, but the inherited access is Read Only unless another mechanism grants more. Study Guide reference: Access to Records - implicit sharing, parent implicit access, Account/Opportunity security, record ownership, and OWD interaction.

System.runAs() is used in Apex tests to execute a block of code in the context of a specified user so that user-dependent record-sharing behavior can be verified. It is particularly useful when the application relies on a Private OWD, role hierarchy, manual or managed shares, or classes declared with sharing. A well-designed test creates representative users, runs the relevant code under those users, and confirms that authorized users can retrieve the intended records while unauthorized users cannot. The key distinction is that runAs() is not itself a production security mechanism and does not replace explicit enforcement of CRUD or Field-Level Security. Object permissions, field permissions, and record sharing remain separate layers that the implementation must enforce appropriately. This question therefore focuses on the sharing aspect of user context rather than on field-level authorization. Study Guide reference: Access to Records - Apex sharing tests, System.runAs(), user context, record visibility, and secure testing of sharing behavior.

Account Teams are designed to model collaboration around an Account while allowing different access levels to the Account and its related Opportunities and Cases. UC can give the sales associate Read access to the Account, Read access to related Cases, and no general Opportunity access through the team configuration. If the associate later needs access to a particular Opportunity, that record can be opened separately through an Opportunity Team or another appropriate sharing mechanism. Introducing separate Case Teams or sharing rules would duplicate functionality that the Account Team already provides for this collaboration model. The design also preserves the Private OWD, because access is granted only to the users explicitly added to the team. Object permissions still apply independently, so the sales associate must have the required object-level Read permission before the team access can be effective. Study Guide reference: Access to Records - Account Teams, related Opportunity and Case access, team roles, Private OWD, and least-privilege collaboration.

The relevant Experience Cloud capability is Super User access, which gives selected external users broader visibility to records belonging to other users associated with the same external account. For Customer Community Plus, the modern terminology commonly used is Portal Super User; the answer choice uses the broader or legacy Partner Super User wording, but it represents the same architectural concept being tested. Delegated external-user administration focuses on managing external users rather than granting broad same-account Case visibility, and a generic community-administration permission is not the record-sharing mechanism required. Super User access should be assigned only to carefully selected agents because it materially expands what they can see within the distributor account. The organization ' s external OWD can remain restrictive between distributors while the elevated user receives the intended same-account visibility. Study Guide reference: Access to Records - Customer Community Plus, Super User access, same-account Case visibility, external-user administration, and Experience Cloud least privilege.

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.

External organization-wide defaults are designed for this exact separation of internal and external access. UC can keep the internal default for Delivery at the level required by employees while setting Default External Access to Private for authenticated external users. That creates a restrictive baseline for distributors 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.

A Default Account Team is designed for sales representatives who repeatedly collaborate with the same internal specialists on customer Accounts. The representative can define recurring team members such as legal, engineering, or finance and specify the access each team member receives to the Account and, where applicable, related Opportunities and Cases. The default team can then be applied automatically to new or transferred Accounts or added to existing Accounts, eliminating the repetitive manual-sharing work described in the scenario. A criteria-based sharing rule is better suited to record access determined by stable record attributes and a fixed audience; it does not model a recurring collaboration team tied to a particular salesperson. View All Data would be dramatically overprivileged because it bypasses record-level controls across the organization. Default Account Teams therefore improve productivity while preserving least privilege and making the collaboration relationship explicit. Study Guide reference: Access to Records - Default Account Teams, team roles, related-record access, collaboration, and least-privilege sharing.

A public group is the appropriate audience because the executives are selected for a specialist responsibility rather than because they all occupy one role. UC can create a group containing only the executives who handle large at-risk deals and share the relevant list views with that group. Using the role hierarchy could expose the views to executives who share the role but do not perform this specialist function. Direct user-by-user sharing is not the standard scalable list-view pattern; a public group centralizes membership and makes later changes easier to administer. As with all list-view sharing, this controls who can see and select the view definition, not who can see the underlying Opportunity records. Each executive still sees only Opportunities permitted by the normal object and record-security model. Study Guide reference: Access to Other Data - list-view sharing, public groups, specialist audiences, scalable administration, and separation of view visibility from record access.