Explanation:

Account Page Layout (Option A):
When an Action Plan is applied to a record (like a Client's Account), it appears in the Action Plans related list. From there, Hank can see the status of the entire plan, but he can also view the individual Tasks and Document Checklist Items associated with that specific client directly on the Account record. This provides the necessary context for the onboarding process.

Standard Salesforce Task List (Option B):
Action Plan tasks are essentially Task records with a specific parent. Because they are standard tasks, they automatically flow into Hank's standard Salesforce Task list and "My Tasks" views. This ensures that Hank doesn't have to navigate to each individual Account to see what he needs to do for the day; all his onboarding responsibilities across different clients are aggregated in one place.

Detailed Explanation of Incorrect Answers

C. Once the Action Plan is assigned, Hank can see the related Tasks on the Timeline:

Reasoning:
While the FSC Timeline component shows life events and general activities, it is not the primary interface for managing and executing Action Plan Tasks. The timeline is designed for a chronological history of a client, whereas Action Plan Tasks are managed via the Action Plan component or the Task object.

D. Hank will be able to see the Action Plan Tasks assigned to him on his calendar:

Reasoning:
In Salesforce, Tasks and Events (Calendar items) are distinct. Tasks have due dates but do not occupy "time blocks" on a calendar unless specifically customized. Action Plan items are created as Tasks, so they will not appear on the standard Salesforce Calendar component by default.

References
Salesforce Help: Work with Action Plans and Templates
Salesforce Help: Add Action Plan Items to the Related List
Trailhead: Automate Repeatable Tasks with Action Plans

Explanation:

This question tests the foundational data model understanding of a Group in Financial Services Cloud. A Group is a core FSC feature for aggregating entities (people, businesses) into a single logical unit for relationship management and reporting.

Why A is Correct: This is a key definition. In FSC, a Group is implemented as an Account record with a specific "Group" record type. The most common and standard subtype of this is the "Household" record type, used to group individual clients (Person Accounts/Contacts) who are part of a family unit. This is a primary FSC construct.

Why C is Correct: This explains how members are associated with a Group. A Group (Account) is linked to its members (which can be People [Contacts/Person Accounts] or Businesses [Business Accounts]) through the Account Contact Relationship (ACR) object. The ACR junction object sits between the Group (Account) and the member (Contact for a person, or Contact associated with a Business Account). This allows for rich role definitions and relationship tracking.

Why the Other Options Are Incorrect:

B: This statement is incorrect because it references the wrong relationship object. The Financial Account Relationship object is used to link Clients (Contacts/Accounts) to Financial Account records (e.g., to define joint ownership). It is not used to relate people and businesses to a Group. The correct object for Group membership is the Account Contact Relationship (ACR).

D: This statement is misleading. While you can create a Group with a "Business" record type to model a collection of related companies (e.g., a corporate conglomerate), this is not a standard, out-of-the-box record type included with FSC in the same way the "Household" record type is. The primary and standard group type is the Household. Business Groups are a possible custom extension.

Reference: The Financial Services Cloud Data Model defines a Group as a specialized Account record. The standard "Household" record type is the primary example. Group membership is managed via the Account Contact Relationship object, which links the Group (Account) to member Contacts (and, by extension, their associated Accounts). This is covered in FSC configuration guides for setting up households and commercial relationships.

Explanation:

Salesforce Financial Services Cloud (FSC) provides out-of-the-box support for Document Checklist Items (DCILs) on the following three standard objects:

C. Account:
Users can track required documents related to a client account, such as a W-9 form for a business account or a proof of identification for an individual account.

D. Residential Loan Application:
This is a key Financial Services Cloud object designed specifically for the lending process. DCILs are extensively used here to manage all necessary documents required during the mortgage application process, such as tax returns, pay stubs, and appraisals.

E. Opportunity:
In standard Salesforce and FSC sales processes, the Opportunity object can leverage DCILs to manage documentation needed during the sales cycle or deal progression, ensuring all required paperwork is collected before closing a deal.

Why the other options are incorrect:

A. Contact:
The standard Contact object does not natively support Document Checklist Items out-of-the-box in the same manner as Account or Opportunity. DCILs are typically related to the broader Account or the specific application/opportunity object.

B. Lead:
Similar to the Contact object, the standard Lead object does not have native, out-of-the-box support for Document Checklist Items. Documentation requirements usually begin once a lead is qualified and converted into an Account/Contact and an Opportunity or Application.

Explanation:

This question tests the fundamental data model dependencies and loading sequence for a Financial Services Cloud migration. Data must be loaded in an order that respects lookup relationships and required fields.

Why C is Correct: This follows the correct dependency chain:
Accounts and Contacts: These are the foundational core records. You must first create the individual client records (as either Person Accounts or as Contacts under Business Accounts, depending on the model). This provides the unique IDs that other objects will reference.

Households (Account Groups): The Household object in FSC is an Account (with a Household record type). It looks up to its member Contacts (and/or Person Accounts). Therefore, the member records (from step 1) must exist before you can create the Household and associate the members to it.

Financial Accounts: The Financial Account object has lookup fields to the Account/Contact (the owner) and often to the Household. These parent records must exist before the child Financial Account records can be created with valid lookups populated.

Why the Other Options Are Incorrect:

A: This sequence is incorrect because it tries to load Financial Accounts before Households. Since a Financial Account often links to a Household, this would likely cause errors due to invalid lookups.

B: This is the most incorrect order. Loading Financial Accounts first is impossible, as they depend on the existence of the owning Account/Contact. Loading "Account groups" last also fails, as it depends on the member Contacts already being loaded.

D: This order is illogical and impossible. Households cannot be loaded first because they require their member Contacts/Person Accounts to exist. Person Accounts (a type of Account) are part of the foundational "Accounts" load, not a separate final step.

Reference:
Standard data migration best practices and the Financial Services Cloud Data Migration Guide emphasize loading records in order of dependency: parent objects before child objects. The FSC-specific hierarchy is: Individuals (Account/Contact) → Groups (Households) → Financial Holdings (Financial Accounts). This ensures foreign key relationships are satisfied and load jobs succeed.

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.