Explanation

Option A (❌) Add a custom Rollup By Lookup (RBL) rule
RBL is a generic Salesforce feature for custom rollups, but FSC already provides prebuilt rollup configuration for households. You don’t need to build a custom RBL rule for Financial Goals.

Option B (❌) Financial Goals cannot be summarized at the household level
Incorrect. FSC supports rollups of Financial Goals to households. This is a key feature for advisors to see aggregated household-level financial planning.

Option C (❌) Create a formula field and add it to the Account page layout
Incorrect. Formula fields can display calculations but they don’t provide summarized rollups across related records. FSC rollups are the correct mechanism.

Option D (✅) Update the selection in "Activities & Objects to Roll Up" to include Financial Goals
Correct. FSC has a configuration setting called Activities & Objects to Roll Up. By adding Financial Goals to this list, the system automatically summarizes them at the household level.

📚 Reference
Salesforce Help: Rollups in Financial Services Cloud
FSC Implementation Guide: Admins can configure Activities & Objects to Roll Up to include Financial Goals, Assets, Liabilities, etc.

📝 Key Takeaway
To summarize Financial Goals at the household level in FSC:
Use the Activities & Objects to Roll Up configuration.
This ensures Financial Goals are aggregated and visible on the household record.

Explanation

As of January 2026, Salesforce FSC continues to emphasize its out-of-the-box (OOTB) industry flows to solve common operational bottlenecks in banking.

Why D is correct: The Send Documents flow for Retail Banking is a prebuilt, templated flow designed specifically to streamline the document collection process. It allows agents to initiate document requests directly from within Salesforce, often integrating with e-signature tools (like DocuSign). Because the request and its status are tracked directly in FSC, customer service agents gain a single, consolidated view of what has been sent, what is pending, and what has been received—eliminating the need to check "multiple systems".

Why others are incorrect:
A: While Marketing Cloud can automate communication, it is an external platform that doesn't inherently solve the problem of agents lacking a unified view of document status within the core FSC service console.

B: Apex is a custom code solution. Salesforce's best practice is to always use declarative tools (like prebuilt Flows) before resorting to custom code.

C: Process Builder is a retired tool that has been superseded by Salesforce Flow. Modern solutions should not be built on Process Builder.

Reference
Salesforce provides industry-specialized workflows in the Lightning Flow for FSC package to automate routine banking tasks.
Salesforce Help: Automate Repeatable Tasks with Action Plans and Flows
Salesforce FSC Admin Guide: Track Required Customer Documents

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:

The core requirement is to roll up customer data at the client and group levels. Rollup by Lookup (RBL) is the specific Financial Services Cloud tool designed to meet this exact need.

Why C is Correct:
Automatic Updates: RBL performs real-time (or near real-time) summary calculations. When the source data (like a Financial Account balance) changes, or when a client's primary group membership changes, RBL automatically recalculates and updates the roll-up fields on the related Client (Person Account) and Group records. This ensures data is always current without manual intervention.

Client and Group Level: This directly addresses the admin's requirement to roll up data at both the individual client and the household/group level. RBL is configured to write summary data to fields on both of these objects.

Primary Group Context: A key feature of FSC's RBL is its intelligence regarding group membership. It can roll up data from a client's financial accounts to their primary group, allowing for accurate household-level wealth and asset summaries.

Why the Other Options Are Incorrect:
A. RBL calculations can not be disabled when importing data into your Salesforce org.
Incorrect. A major best practice for large data imports is to temporarily disable RBL rules to prevent performance issues and validation errors during the load process. They can be easily enabled again after the import.

B. An RBL rule displays summary calculations of financial account information, such as account balances.
This is partially true but incomplete/misleading. While RBL does perform these calculations, the key functionality is not just "displaying" them. Its primary function is to write and store those calculated summaries into fields on the Client and Group records (as stated in option C). Option B describes the what, but option C correctly describes the how and where.

D. Rollups for multiple joint owners are not supported.
Incorrect. This is a critical feature of FSC's RBL. It is explicitly designed to handle pro-rata allocation for joint financial accounts. The system can correctly split the value of an account (e.g., a 50/50 joint checking account) and roll up the appropriate portions to each individual client's record and their respective groups.

E. Rollup By Lookup (RBL) displays associated records for Financial Accounts, Financial Goals, and Opportunities.
Incorrect. This describes a related list, not a rollup. RBL does not "display associated records"; it performs mathematical calculations (SUM, AVG, COUNT, etc.) on the data within those records and stores the result in a number/currency field.

Key References & Concepts:
Primary Object: The process starts with a Rollup Summary Definition (e.g., "Total Household Assets"), which defines the calculation.

Mechanics: It uses a Lookup Relationship from the source object (e.g., Financial Account) to the target object (Client or Group) to perform the calculation and write the result to a field on the target record.

Use Case: Enables Advisors to instantly see key metrics like Total Assets Under Management (AUM) or Total Household Balance directly on the Client and Group record pages, which is fundamental to the 360-degree client view in FSC.

Documentation: The Salesforce Help article "Set Up Rollup by Lookup" covers the configuration and pro-rata allocation logic in detail.

Explanation

Option A (✅): Register a subdomain using the My Domain wizard and then deploy it
Correct. The admin must go to Setup → My Domain, register a custom subdomain, test it, and then deploy it to all users. This is the official process to enable My Domain.

Option B (❌): Open a case with Salesforce Support
Incorrect. My Domain can be enabled directly by the admin in Setup. No support case is required.

Option C (❌): Enable Communities
Incorrect. Communities require My Domain, but enabling Communities does not itself enable My Domain.

Option D (❌): Go to Custom Settings and edit the Industries Settings
Incorrect. Industries Settings are unrelated to My Domain.

📚 Reference
Salesforce Help: Set Up My Domain
FSC Implementation Guide: My Domain is required for Lightning Components, FSC features, and secure login policies.

📝 Key Takeaway
To enable My Domain:

Use the My Domain wizard in Setup.
Register a subdomain, test it, and deploy it.

This unlocks FSC Lightning Components and other advanced features.