Free Salesforce Plat-Arch-205 Practice Exam with Questions & Answers | Set: 3

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.

Site User Visibility controls whether authenticated Experience Cloud users can discover other users who participate in the same site. Turning the setting off therefore affects searching for and seeing other external site users. The setting is part of the broader User-object sharing model, which is distinct from sharing business records such as Accounts, Cases, and Opportunities. It does not primarily control whether a user can edit the user ' s own profile, and it should not be interpreted as a general switch for internal-user search. Experience Cloud architects must treat user visibility as its own privacy problem because exposing the User directory can reveal names and other profile information even when business data is correctly isolated. The organization should therefore combine the User object ' s OWD and site/portal visibility settings with any required user-sharing rules according to the collaboration experience it intends to provide. Study Guide reference: Access to Other Data - User sharing, Site User Visibility, Experience Cloud user discovery, external-user privacy, and User-object access controls.

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.

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.