Explanation:

In Financial Services Cloud (FSC), rollups aggregate data (activities, opportunities, financial accounts, etc.) from primary group members up to the household or group level.

For Scott’s data to roll up to the Adams Household, the banker must:
- Set the Adams Household as Scott’s primary group.
- Configure the Activities & Objects to roll up so that Scott’s records (e.g., savings account activity) are included in the household view.

This ensures that Rachel, as the primary member, and the banker can see Scott’s joint account information at the household level.

❌ Why not the other options?
B. Add Scott as a Related Contact to the Adams Household → Related contacts don’t trigger rollups; only primary group membership does.

C. Make the Adams Household Scott’s primary group and make Scott the primary member → Making Scott the primary member would incorrectly replace Rachel as the household’s primary member.

D. Disable the Primary Group setting for Scott on the Adams Household → This would prevent rollups entirely, which is the opposite of what’s needed.

📚 Reference:
From Salesforce FSC documentation:
“Record rollups aggregate information from primary group members to the household or business group. To enable rollups, set the household as the client’s primary group and configure the rollup settings for activities and objects.”

Explanation:

B. Ensure RollUpByLookup Configuration is Active:
Why it's correct: In FSC, Rollup By Lookup (RBL) is the specific technology used to aggregate numeric values (like account balances) from the Financial Account object up to the Account/Household level. These are managed via the Rollup By Lookup Configuration custom metadata or settings. If the specific RBL rule for "Total Financial Account Balance" is inactive, the system will not update the summary field, even if the data is correct.

E. Ensure the reported Household is the Primary Group for the member:
Why it's correct: As established in the FSC data model, an individual can belong to multiple groups, but the system only rolls up financial data to the group designated as the Primary Group (via the Account Contact Relationship record). If the Household in question is not marked as "Primary" for that specific member, their individual balances will not be included in that Household's summary total.

Analysis of Incorrect Answers
A. Ensure the Primary Group flag in the Account record is checked:
Why it's incorrect: The "Primary Group" checkbox is not located on the Account record itself; it is a field on the Account Contact Relationship (ACR) record that connects the person to the household.

C. Ensure a RollUpByLookup batch job is scheduled to run every 15 mins:
Why it's incorrect: While RBL can be run in batch mode, it is typically triggered in real-time or via a daily batch job. There is no standard requirement or recommended "15-minute" interval for this specific job, and if the configuration is inactive (Option B), the frequency of the job won't matter.

D. Ensure that the member is the Primary Member in that Household:
Why it's incorrect: Every member of a household can have their balances roll up to the total, not just the "Primary Member." A child’s savings account or a spouse’s IRA will roll up to the Household total as long as the Household is their Primary Group.

Reference
Salesforce Help: Rollup By Lookup (RBL) in Financial Services Cloud
Salesforce Help: Set Up and Configure RBL Rules

Explanation:

In Salesforce Financial Services Cloud (FSC), the Life Events or Business Milestones Lightning component (added to record pages like Person Account or Household) displays events and milestones based on their Event Type or Milestone Type.

To restrict users from viewing certain types that are irrelevant or could cause negative sentiment (e.g., sensitive events like "Divorce" or "Death"):
- Edit the Lightning Record Page in App Builder.
- Select the Life Events or Business Milestones component.
- In the Properties pane, there is a section to select/deselect specific Event Types or Milestone Types to show or hide them in the component.

This declaratively hides selected types across all users viewing the page, preventing display of potentially sensitive or irrelevant milestones without affecting data creation or other views.

Why not A? Sharing rules control record-level access (who can see individual Life Event records), not the visibility of entire event types in the component.

Why not B? Removing a value from the Event Type picklist would prevent creation of that type entirely (and could impact existing records), which is too restrictive and not the intended way to hide display in the component.

Why not D? Permission sets control object/field access or feature permissions but do not filter specific picklist value types within the Life Events component.

References:
Salesforce Help: Hide Sensitive Event Types and Milestone Types – Describes configuring visibility of event/milestone types directly in the component properties.
Trailhead: Insurance for FSC Admin modules (e.g., Set Up Life Events and Business Milestones) – Covers adding the component and customizing displayed types via properties.
FSC Documentation & Release Notes: Confirms selective hiding of types in the Lightning component properties pane for sensitivity or relevance.

Explanation:

Why this is correct
An OmniScript (OmniStudio) is designed for guided, multi-step agent scripts (perfect for call center authentication) and can:
- Collect input that isn’t stored in Salesforce (captured as JSON during the interaction)
- Execute external service callouts using Action elements (often via an Integration Procedure that performs HTTP actions / API calls)
- Support conditional/branching logic and step-by-step screens for agents

Salesforce explicitly describes OmniScripts as guided interactions that can get/update data from Salesforce and external data sources, and notes that OmniScript actions can use APIs / Integration Procedures to call external systems.

Why the other options are less suitable
A. Screen Flow — Flows can integrate with external services (e.g., HTTP Callout / External Services), but the scenario is a classic Industries/FSC guided agent script pattern where OmniScript is the intended tool, especially when capturing transient inputs and orchestrating an external verification step.

B. Lightning Web Component — Would require custom development for the UI and integration orchestration; not necessary when OmniScript provides this declaratively.

C. Canvas application — Overkill for a guided authentication script; Canvas is typically used to embed an external UI app inside Salesforce.

Explanation:

A. Add the Business record type to the Group record type mapper
To model a commercial customer as a “Group” (not just a generic business account), FSC uses record-type mapping so Salesforce knows which custom/Account record types should behave like standard FSC Group types. This is done through GroupRecordTypeMapper (custom metadata) which maps your custom Group record type(s) to FSC’s standard group behavior.

D. Enable Relationship Group Hierarchy in Custom Metadata
Because the commercial customer can be owned by multiple groups and you also need to display the commercial customer and its parent company, you enable Relationship Group Hierarchy so FSC can represent and visualize group-to-group hierarchies/relationships (expanded relationship group hierarchies). Salesforce explicitly calls out enabling this via the Enable Relationship Group Hierarchy custom metadata types.

E. Link multiple owners to the business entity as a Group
FSC’s Party Relationship Groups are designed to connect clients, households, and business entities, and can include relationships to other groups—which is the right pattern when a business entity can be associated with multiple owning groups.

Why the others aren’t correct
B. Capture the majority owner as parent account using Account hierarchy — Account hierarchy is standard Salesforce, but it doesn’t address the FSC requirement of multiple group ownership and FSC relationship-group modeling.

C. Leverage Groups to capture the majority owner and Account hierarchy to capture minority owner — This mixes two different modeling patterns in a way that doesn’t align with FSC’s intended group-to-group relationship/hierarchy approach for multiple owning groups.

Explanation:

Why it's correct: Salesforce enforces a rule that every record must be owned by a User or a Queue. When using the API (which Data Loader utilizes), if a specific owner is not provided during an Insert operation, the system automatically assigns ownership to the context user—the person whose credentials were used to log into the Data Loader.

The "Blank" Logic: Since the administrator is logged in, their User ID is used as the default value for the OwnerId field for all successfully inserted records in that batch.

Analysis of Incorrect Answers
Option [A]: The import will succeed, and the Account Owner field will be left blank.
This is impossible in Salesforce for the Account object. OwnerId is a system-required field. A record cannot exist without an owner.

Option [B]: The import will succeed, and the administrator will be prompted to select a user.
Data Loader is a bulk processing tool and does not provide interactive prompts during the execution of a job. It relies entirely on the CSV mapping and the user's settings.

Option [C]: The import will fail, since all records in Salesforce must have an owner.
While it is true that all records must have an owner, the import won't fail for this specific reason. Salesforce handles the requirement by defaulting to the user performing the upload. The import would only fail if the user lacked "Create" permissions or if other required custom fields were missing.

Reference
Salesforce Help: Data Loader Considerations
Salesforce Developers: Insert, Update, or Delete Data Using Data Loader

Explanation

As of January 2026, Compliant Data Sharing (CDS) remains the primary FSC feature designed for granular, role-based record visibility required by strict regulatory environments.

Why A is correct: Compliant Data Sharing allows administrators and compliance managers to define Participant Roles (such as "Legal Observer" or "Compliance Officer") with specific access levels (Read or Read/Write). It is specifically built for scenarios where specific records—such as high-value Deals or Accounts—must be shared with users who are not part of the standard account team or role hierarchy. It provides a "clicks-not-code" way to manage access to sensitive data, including Material Non-Public Information (MNPI).

Why others are incorrect:
B: While standard Sharing Rules can grant access, they are typically broad (based on public groups or roles) and lack the granular, record-by-record "Participant" model required for specific deal-based engagement.

C: The Business Rules Engine is used for automating complex decision-making logic (like calculating loan eligibility), not for record-level security and visibility.

D: Interaction Summaries are used to capture meeting notes and call logs; while they integrate with CDS to ensure notes are shared securely, they are not the mechanism that provides the visibility to the underlying Account or Opportunity.

Reference
To learn more about implementing this security model, refer to the Salesforce Help: Compliant Data Sharing and the Salesforce Architect's Guide to CDS.

Explanation:

Chatter components (like the Chatter publisher or feed) can only be added to a Lightning record page if Feed Tracking is enabled for that specific object. This applies to standard and custom objects, including the Action Plan object in Financial Services Cloud.

A. Correct: Feed Tracking must be enabled for the Action Plan object (Setup → Object Manager → Action Plan → Feed Tracking). Without this, Chatter components won't appear in the Lightning App Builder component palette for that object's record page.

B. Incorrect: Chatter is enabled org-wide, not per object via Chatter settings. The issue is object-specific feed tracking, not global Chatter activation.

C. Incorrect: Chatter is fully supported for the Action Plan object once Feed Tracking is enabled. There's no pending rollout limitation.

D. Incorrect: Permission sets control user access to records or features, but don't affect whether Chatter components are available in Lightning App Builder for page editing.

References:
Salesforce Help: “Enable Chatter Feed Tracking for an Object” – explains that feed tracking must be enabled to use Chatter components on record pages.

Lightning App Builder Guide: “Add Chatter Components to Record Pages” – states Chatter components only appear if the object has feed tracking enabled.

Explanation:

Flow Builder in Salesforce excels at creating guided, interactive processes, particularly through Screen Flows. These flows allow administrators to build wizard-like forms with screens, input fields, conditional logic, and data operations (create/update records, queries, etc.).

The best fit among the options is a Screen Flow that:
Collects user input via screens (e.g., a multi-step form).
Is embedded on a Lightning record page or utility bar.
Is launched via a button, quick action, or hyperlink.

This is a classic and highly recommended use case for Flow Builder—replacing manual data entry with guided, validated, error-reduced processes (e.g., custom case creation, client onboarding steps, approval requests).

Why not A? Coordinating multiple flows and assigning them to teams/individuals is better suited to Process Builder (deprecated) or Flow Orchestrator (now part of Salesforce Orchestrator), which manages multi-step, multi-user workflows across flows.

Why not B? Suggesting tailored offers/actions based on business criteria is the domain of Einstein Next Best Action or Einstein Recommendation Builder, not standard Flow Builder.

Why not D? Performing operations on more records than schedule-triggered flows allow points to Apex batch jobs or Bulk API, as schedule-triggered flows have governor limits (e.g., 250,000 records per hour or lower depending on type). Flows are not designed for massive bulk processing beyond those limits.

References:
Trailhead: Flow Builder Basics – Highlights Screen Flows for guided data collection launched from buttons.
Salesforce Help: Screen Flow Use Cases – Common examples include forms on Lightning pages.
Salesforce Automation Decision Guide: Recommends Flows for interactive user processes, Orchestrator for coordination, and Einstein for recommendations.

Explanation:

A. Repeatable tasks & automation
Action Plans let admins define templates of tasks for common processes (like loan approvals).
When executed, they automatically generate the sequence of tasks, saving time and ensuring consistency.

B. Default assignment to record owner
If an Action Plan template task doesn’t have a user assigned, Salesforce automatically assigns it to the owner of the target record (e.g., the loan application record).
This prevents tasks from being left unassigned.

D. Collaboration & productivity
Action Plans improve teamwork by auto-assigning task owners and deadlines.
This ensures accountability and speeds up processes like loan approvals, where multiple stakeholders are involved.

❌ Why not the other options?
C. Automatically schedule the next appointment with the Advisor
→ Action Plans don’t schedule appointments; they generate tasks. Appointment scheduling would require Flows or Calendar integrations.

E. Speed up collection of documents
→ Document collection is handled by Send Documents flow for Retail Banking, not Action Plans. Action Plans focus on task orchestration, not document intake.

📚 Reference:
From Salesforce FSC documentation:
“Action Plans provide repeatable task templates that automate task sequences, assign owners, and set deadlines to streamline client processes.”

Explanation:

Why they are correct: Interest Tags in FSC rely on the underlying Salesforce "Topics" architecture but are enhanced with industry-specific capabilities. Salesforce includes the necessary user permissions within two primary managed permission sets:

FSC Foundations: This permission set provides access to the core data model and foundational features of Financial Services Cloud, including Financial Accounts, Households, and the base Interest Tagging functionality.

FSC Extension: This permission set extends the core platform with additional features like Action Plans and advanced relationship tools. It also contains the "Access Interest Tags" permission to ensure that users working with these extended features can still leverage the tagging system.

The Cloning Strategy: Since managed permission sets cannot be directly edited to add custom object permissions (like specific Tag Category access), administrators clone FSC Foundations or FSC Extension as a starting point. This ensures all underlying system permissions are preserved while allowing the admin to add specific object-level security.

Analysis of Incorrect Answers
Option [C]: FSC Standard permission set
While "FSC Standard" is a common term in licensing, the specific managed permission set provided in the package for the purpose of foundational access is named FSC Foundations. In the context of the AP-208 exam, "Standard" is often a distractor for "Foundations."

Option [D]: FSC Basic permission set
The "FSC Basic" permission set is typically used for restricted users (like bank tellers) who have limited access to the data model. It usually does not include the specialized "Access Interest Tags" permission required for advisors to manage and assign client interests.

Reference
Salesforce Help: Interest Tags Editions and Permissions
Salesforce Help: Financial Services Cloud Permission Sets

Explanation:

D. The Person Account is a virtual object displaying data from Accounts and Contacts objects…
This is true: Person Accounts combine Account + Contact fields into a single “person” record experience. Salesforce describes person accounts as storing information about individuals by combining certain Account and Contact fields into one record.

E. The Person Account model uses the standard Account object…extended with custom fields and a Person Account Record Type
Also true: Person Accounts are implemented using the standard Account object (with a Person Account record type and person-specific fields/behavior). Salesforce documentation explicitly describes person accounts as extending standard account functionality for B2C use cases.

Why the others are not true (high level)
A is false: you can’t merge a Person Account with a Business Account.
B is misleading: Person Account access is fundamentally Account sharing (Contacts are often “controlled by parent”), so it’s not accurate to say you must create sharing rules for both Account and Contact to share a Person Account.
C may describe a possible business scenario, but it’s not a defining “data model truth” compared to D/E, and the question asks specifically about the Person Account data model.