Explanation:

B. Expressed interests
FSC referral components track areas of interest (needs) from referrals. On the FSC Home page, the “Summary of Referrals Assigned to Me” component explicitly provides an overview including “top areas of interest”, which maps to Expressed Interest tracking.

C. My Top Referrers
“My Top Referrers” is one of the standard FSC custom components on the Home page, used to track who is sending you the best referrals.

E. Referrals Assigned to me
“Referrals Assigned to Me” is also a standard FSC Home page custom component showing the top referral needing action (i.e., referral workload assigned to the user).

Why the other options are not correct:

A. Web to Lead Referrals – Web-to-Lead is a Lead capture mechanism, not a standard FSC referral metric component.

D. My Approved Referrals – This isn’t one of the standard FSC referral custom components called out for tracking referral activity on the Home page.

Explanation:

A. The Broker Assistant should be modeled as a Contact. Then, leverage Contact to Multiple Account features if this assistant needs to work for multiple brokers.
Reasoning: In a broker portal scenario, an assistant is a person (Contact). To satisfy Requirement #4 (assisting multiple brokers), the Account Contact Relationship (ACR) feature—also known as Contact to Multiple Accounts—is the standard Salesforce and FSC solution. This allows the Assistant Contact record to be related to multiple Broker Accounts, enabling the assistant to switch contexts or view data for different brokers they support without duplicating records.

B. Brokers should be modeled as Contact and the Broker company should be modeled as Account, even if they're a legal entity individually.
Reasoning: In insurance distributions, the "Broker Company" is the legal entity (Account) that holds the contract and receives commissions, while the "Brokers" themselves are individual professionals (Contacts) associated with that firm. Modeling the individual broker as a Contact ensures that Requirement #2 (data isolation) can be easily managed via Private Sharing Models or External Account Hierarchy in the portal, where access is restricted to the specific Contact and their related data.

Why the other options are incorrect:

C. Brokers need to be modeled as Account and Contact individually... use a Group 1-1 Account to model their company.
Reasoning: This adds unnecessary complexity and deviates from the standard Insurance and FSC data models. Modeling every individual broker as a separate "Account" makes managing the relationship with the overarching "Broker Company" (the parent firm) difficult and complicates reporting on the brokerage's total book of business.

D. The Broker Assistant should be modeled as a Contact. Then, use Contact to Contact association if they need work for multiple brokers.
Reasoning: Contact to Contact relationships in FSC are typically used to model personal or professional influence (e.g., "Friend of" or "Lawyer for"). While it captures the relationship, it does not grant the Portal Access or Security Permissions required for an assistant to see the broker's accounts, policies, or claims. Access in Salesforce Experience Cloud (portals) is driven by the Contact's relationship to the Account, making the Account Contact Relationship (Option A) the technically correct choice for permissions.

Reference:
For 2026 best practices on insurance distribution models, refer to the Salesforce Insurance Data Model and Contact to Multiple Accounts documentation.

Explanation:

Irreversibility (Option B): This is the most significant technical limitation. Once Person Accounts are activated in a Salesforce organization, the feature cannot be disabled, not even by Salesforce Support. Because enabling it fundamentally alters the data model (merging Account and Contact behaviors into a single record type), there is no automated way to "un-merge" the metadata. Organizations are strongly advised to test this in a Sandbox environment first.

Salesforce Inbox Constraints (Option C): While Salesforce Inbox is a powerful tool for syncing email and calendar data, it has specific limitations regarding Person Accounts. Specifically, the ability to create new client records (as Person Accounts) directly from the Inbox sidebar is not supported. Users can still link emails to existing Person Accounts, but the creation of a new one must be done within the Salesforce core UI.

Detailed Explanation of Incorrect Answers

A. Person Accounts can be enabled and disabled only by contacting Salesforce Support.
Reasoning: While in the past you had to contact Support to enable Person Accounts, it can now be enabled directly by an Administrator in the Setup menu (provided certain prerequisites are met). However, as mentioned above, they can never be disabled once activated, which makes this statement false.

D. AppExchange packages will not work if Person Accounts are enabled.
Reasoning: Most modern AppExchange packages are fully compatible with Person Accounts. While some older or highly specialized apps might require specific configurations to handle the unique Account/Contact relationship of a Person Account, the blanket statement that packages "will not work" is incorrect. Developers can specify "Person Account Compatibility" in their AppExchange listings.

References
Salesforce Help: Enable Person Accounts
Salesforce Help: Considerations for Using Person Accounts
Salesforce Knowledge: Cannot Disable Person Accounts

Explanation

Option A (❌) Referral Scoring
Referral Scoring uses Einstein AI to prioritize referrals based on likelihood of conversion. It does not aggregate or display referrals across group members.

Option B (✅) Referrals Rollups
Correct. Referrals Rollups allow referrals to be rolled up to the group level, so users can see all referrals associated with household or group members. This is the feature that enables visibility across the group.

Option C (❌) Group Member Referrals
Not a standard FSC feature. Likely a distractor. Referrals are managed via rollups, not a “Group Member Referrals” setting.

Option D (❌) Referral Group Process Builder
Incorrect. Process Builder can automate referral workflows, but it is not the feature that enables group-level visibility.

📚 Reference
Salesforce Help: Referrals in Financial Services Cloud
FSC Implementation Guide: Referrals Rollups aggregate referrals at the household/group level for visibility.

📝 Key Takeaway
To allow users to see all referrals for group members in FSC:
Enable Referrals Rollups.
This ensures referrals are aggregated and visible at the household or group level.

Explanation:

In Salesforce Financial Services Cloud (FSC), the Interaction Summary object is specifically designed for investment bankers, relationship managers, and other financial services professionals to capture detailed meeting notes, discussion points, outcomes, and follow-ups from client or internal meetings.

Key capabilities that match the scenario:

Detailed meeting notes — Interaction Summaries allow rich text notes, structured sections, and attachments for comprehensive documentation.
Easy sharing with colleagues — Summaries are visible in the client 360° view, Relationship Map, and can be shared via Chatter, email notifications, or assigned as tasks/follow-ups to team members.
Specifying confidentiality — You can control visibility using Sharing Rules, Field-Level Security, Permission Sets, or mark the summary as Private (via custom fields or record types). Sensitive information can also be protected using Enhanced Sharing or Private Notes features.
Meeting attendees — The Interaction Summary includes standard fields (or customizable ones) to record Participants/Attendees (linked to Contacts, Person Accounts, or Users), making it clear who was involved.

Why not the others?

A. Notes — Standard Salesforce Notes (enhanced or classic) are simple, lightweight, and lack FSC-specific structure, attendee tracking, or built-in confidentiality controls tailored for financial services interactions.

B. Events — Events (Calendar entries) are great for scheduling meetings and tracking attendees, but they are not designed for detailed note-taking or post-meeting documentation/sharing.

C. Engagement Interaction — This is a lower-level object used internally for tracking engagement metrics (e.g., call logs, emails), but it is not the primary place for rich, shareable meeting notes in FSC.

Recommendation for the consultant:
Recommend Interaction Summary as the best-practice feature in FSC for documenting client meetings in wealth management/investment banking. It provides the right balance of detail, collaboration, visibility control, and compliance alignment (e.g., for MiFID II, SEC record-keeping requirements).

Reference:
Salesforce FSC documentation and Trailhead modules on "Client Engagement and Interactions" highlight Interaction Summaries as the go-to object for capturing and sharing meeting details in a secure, collaborative way within financial services teams.