FSC Relationship Model: Households, Financial Accounts & Roles

Relationship management in Financial Services Cloud: households, financial accounts, and roles

The short answer

In Salesforce Financial Services Cloud (FSC), relationship management is built around three connected building blocks: households (groups), financial accounts, and roles/relationships. Households help you model real-world family or entity structures, financial accounts capture what a client “has” (accounts, assets, policies, loans, etc.), and roles define how people relate to households, businesses, and each other, so teams can work from a true relationship view instead of disconnected records.

When to implement Financial Services Cloud

Most financial institutions don’t serve “one customer, one product.” They serve households and connected relationships across multiple accounts and products. FSC is designed to reflect that reality by letting you model:

  • An individual client (often as a Person Account)

  • Their household/group (typically represented as a business account + group membership model)

  • Their financial accounts (what they own/hold)

  • The roles that connect everything (who is spouse, beneficiary, decision maker, advisor contact, etc.)

This matters because your advisors, bankers, and service teams can’t act confidently unless they can answer: Who is connected to whom, and what do they own together?

Use this decision logic to implement FSC relationship management cleanly:

  • If you sell/serve at the family level → you need households/groups as the organizing layer, not just individual records.

  • If “what the client owns” drives next best actions → you need the Financial Account data model to represent accounts, assets, and financial products consistently.

  • If multiple people influence decisions → you must define roles/relationships explicitly (not in notes), so workflows, permissions, and reporting work reliably.

1) Households and groups: how FSC models them

In FSC, households and other “groups” are modeled in a structured way so you can represent real-life relationship groupings (households, related households, organizations tied to a household, etc.).

What to know

  • FSC provides built-in ways to track households and groups using party relationship groups / group membership concepts.

  • A common pattern is:

    • Business Account represents the household entity

    • Members are related through relationship records (so each person can have a defined role in the household)

Why marketers and ops teams should care

Householding is what enables:

  • household-level visibility for cross-sell/upsell (without guessing)

  • consistent service delivery (who can authorize changes, who gets communications)

  • reporting by relationship groups, not just by individuals

2) Financial accounts: how FSC represents “what clients have”

Financial Services Cloud adds a financial-services-focused data model on top of core Salesforce objects, including a Financial Account Data Model to help represent financial accounts, assets, and more.

What “Financial Accounts” unlock

When financial accounts are modeled consistently, teams can:

  • view the client relationship in context (not scattered across systems)

  • tie workflows to the real product relationship (onboarding, servicing, reviews)

  • support relationship-based insights and segmentation

Salesforce Help explicitly documents how FSC models financial accounts and relationships within its data model guidance.

3) Roles and relationships: how FSC connects people to households and accounts

FSC relationship management is not just “linking records.” It’s assigning meaningful roles to those links.

The three relationship tools you’ll use most

Salesforce’s FSC learning materials break relationship modeling down into specific relationship record types/objects, including:

  • Account-contact relationships (connect a person to a business account, such as a person to their household or employer, and define the nature of that relationship—like decision maker)

  • Party role relationships (describe relationships between people/companies to reflect real-world connections)

  • Party relationship groups (organize members under a household/group and connect related households or associated businesses)

Why role clarity matters

When roles are structured:

  • your service team routes work correctly

  • your communications target the right people

  • your reporting reflects reality (not assumptions)

What you can model cleanly

These are the kinds of relationship questions FSC can support when modeled well:

  • “Show me everyone in this household and their roles.”

  • “Show me the household’s financial accounts and related records.”

  • “Show me decision makers vs beneficiaries vs authorized contacts.”

Quick implementation checklist for householding + relationship model

Use this checklist to avoid the most common FSC relationship modeling mistakes:

  1. Choose your client record approach (many FSC patterns use Person Accounts for individuals).

  2. Define household/group rules

    • What counts as a household?

    • Can one person belong to multiple groups? (common in real life)

  3. Standardize role taxonomy

    • spouse, child, beneficiary, decision maker, authorized signer, etc.

  4. Map financial account sources (where accounts/assets/policies originate and how they’ll sync)

  5. Validate with real scenarios

    • 3–5 real households, 1–2 edge cases (blended families, trusts, shared accounts)

  6. Document it (one-page relationship blueprint your admins and data team can enforce)

Talk with a Financial Services Cloud expert

Financial Services Cloud relationship management works when you model the world the way financial services actually operates: households/groups, financial accounts, and role-based relationships that connect them all. When that foundation is right, everything else, onboarding, service, segmentation, and reporting, gets easier.

Book time with our team if you want help designing (or fixing) your FSC relationship model. We’ll walk through your householding rules, role taxonomy, and financial account data approach so your implementation supports real workflows, not just a clean diagram.