Helping Hand Questions for Plat-Arch-205

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.

Partner Community is the appropriate external license model because the distributors participate in a B2B sales process and require Opportunity visibility. Partner-oriented licenses support the external role hierarchy and the sales-object collaboration model needed for channel users such as distributors and resellers. Customer Community is primarily aimed at high-volume customer self-service and does not provide the same Opportunity-oriented partner model. Customer Community Plus adds more advanced sharing than basic Customer Community, but it is not the primary licensing model for external channel sales collaboration. At the scale described, the architect must also design the partner role hierarchy and external sharing model carefully so that one distributor cannot see another distributor ' s records and so that role/group proliferation does not create unnecessary sharing complexity. The license defines the ceiling of what the external user can do; UC must still configure object permissions and record-level sharing to expose only the Opportunities relevant to each distributor. Study Guide reference: Access to Records - Experience Cloud licensing, Partner Community, Opportunity access, partner roles, external sales collaboration, and scalable partner 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.

Public Read-Only is the correct Lead OWD because it balances duplicate prevention with ownership-based editing. Users can see existing Lead records across the organization, which helps them identify whether a prospect already exists before creating another Lead, but they cannot edit another user ' s Lead merely because they can view it. A Private OWD would protect ownership more strictly but would undermine the duplicate-reduction objective because users might not be able to discover Leads owned elsewhere. Public Read/Write/Transfer would go too far in the opposite direction by allowing broader modification or reassignment than the requirement permits. The organization can complement the OWD with Duplicate Rules and Matching Rules for stronger prevention and warning behavior, but the OWD still establishes the right record-visibility baseline. Study Guide reference: Access to Records - Lead OWD, Public Read-Only, record ownership, duplicate prevention, and least-privilege access. 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.