Wealth management runs on relationships, and relationships in wealth almost always sit at the family level. A primary client owns one set of accounts. A spouse owns another. Children hold custodial accounts. A family trust owns something else. The advisor's job is to manage the relationship, not the account, and the natural unit of the relationship is the household.
Financial Services Cloud ships the Household object as the FSC-standard way to represent this. The shape is non-obvious. Household is not a custom object. It is not a relationship junction. It is a Record Type on the Account object, with a fixed set of conventions about what attaches and how rollups flow.
Why Household is an Account record type
The first time most teams encounter Household, they expect a separate object. A standalone Household with lookups to family members would feel cleaner. The FSC team chose Account-as-Household for a specific reason: rollups.
The standard Salesforce rollup engine works on master-detail relationships. Households are not master-detail with their members, because a person can move households (divorce, remarriage, custody change) without losing identity. Households are not custom rollups either, because the calculation needs to happen in real time across multiple member records and multiple financial accounts.
Making Household an Account Record Type means it uses Rollup By Lookup (RBL), the declarative rollup engine FSC ships specifically for this shape. Household rolls up Financial Accounts owned by its members, summing assets under management, deposits, loans, and any other balance category the implementation tracks. The rollup runs without custom Apex and without manual scheduling.
The members-and-roles model
Members attach to a Household through Account Account Relationship, a junction object between two Account records. One side is the Household record; the other side is each member's Person Account. The junction carries a Role field that captures the relationship: Primary, Spouse, Child, Dependent, Trustee, Trust Beneficiary, Power of Attorney.
A typical Household structure for a wealth client:
- Household record: "The Persona-A Family".
- Account-Account Relationship: Persona A -> Primary.
- Account-Account Relationship: Persona A's spouse -> Spouse.
- Account-Account Relationship: Child 1 -> Child.
- Account-Account Relationship: Child 2 -> Child.
- Account-Account Relationship: family trust (Business Account) -> Related Entity.
Each member also exists as a Person Account in their own right, with their own contact details, their own financial accounts, and their own activity history. The Household record aggregates rather than replaces.
How rollups actually flow
Three layers stack:
Financial Accounts roll up to their Primary Owner. A current account at the bank, owned by a member, contributes its balance to that member's total deposits. A joint account between two members can be split by Primary Owner percentage.
Member totals roll up to the Household. RBL sums each member's deposits, investments, and loans up to the Household-level fields like TotalAssets, TotalLiabilities, NetWorth, and AssetsUnderManagement.
Household totals feed advisor dashboards. The Wealth Console shows the household's combined net worth, asset allocation, and recent activity. The advisor sees the relationship view; the underlying member-and-account view is one click away.
The rollup is real-time when the source record is updated. Changes flow through within seconds in normal volume. At very high data-volume scale (multi-million account orgs), batch refresh tools exist to recompute lagging rollups, but most production orgs never need them.
The sharing trap
The most common Household mistake in production is sharing. The default Salesforce sharing model treats Household and member records as separate Accounts. An advisor with access to the Household record does not automatically have access to member records. An advisor with access to one member does not automatically have access to the Household.
For a relationship-driven advisor experience, this is wrong. The whole point of Household is unified visibility.
FSC's answer is Compliant Data Sharing (CDS), an optional managed package that bridges the gap. CDS lets an admin define sharing rules that follow the Account-Account Relationship junction. An advisor granted access to a Household can be configured to gain access to all member Accounts and their Financial Accounts through CDS rules.
The trap: not every implementation knows to enable CDS for Household sharing. Teams that skip CDS often build manual sharing rules with Apex or Flow that approximate the same behaviour but drift over time. CDS is the right answer for any wealth-management org with multi-member households.
Group versus Individual household
A subtle data-model choice every implementation faces is whether single-person clients get a Household record at all. Two valid patterns:
Individual-household pattern. Every client gets a Household, even if they are the only member. The single-person Household contains one Account-Account Relationship to the client as Primary. Advisors see a consistent Household-centred view regardless of family size. Reporting is uniform.
Group-household-only pattern. Only multi-member relationships get a Household. Single-person clients show up directly as Person Accounts with no Household wrapper. Less metadata, but the advisor view differs between single and multi-member clients.
Sapota typically recommends the individual-household pattern. The cost (one extra Account record per client) is negligible. The benefit (one consistent advisor view across the whole book) is meaningful. The pattern also future-proofs the data shape: when a single-person client marries, the Household already exists, ready to accept new members.
Household and the joint-account problem
Joint accounts (a bank account, brokerage account, or investment product owned by two or more people) need careful modelling. Two options inside FSC:
Single owner with related parties. The Financial Account has one Primary Owner. The other owners attach via Financial Account Role records with the Joint Owner role. RBL rolls the full balance to the Primary Owner. Cleaner reporting at the member level, but the non-primary joint owner does not see balance contribution on their member rollup.
Split-percentage rollup. A custom rollup configuration splits the balance proportionally between joint owners. Each owner sees their share. More accurate per-member rollups; more complex configuration; small drift risk if the percentages do not sum to 100.
Most retail-banking implementations stick with single-owner-plus-roles. Most high-net-worth implementations move toward split-percentage for precision. The choice should be made at data-model design, not at first-joint-account creation.
What to verify on Day One
For an FSC implementation reaching the Household stage:
- Account Record Types include Household alongside the line-of-business Person Accounts and Business Accounts.
- Account-Account Relationship Role picklist matches the relationships the business actually tracks.
- RBL summary fields exist on Household for every balance category that will appear on advisor dashboards.
- Compliant Data Sharing is enabled and configured for Household-to-member access propagation.
- Sandbox data includes at least one multi-member Household with multiple Financial Accounts so the rollup chain can be validated end-to-end.
Skipping any of these surfaces the gap the first time an advisor opens the Wealth Console and sees a partial view of the household.
Designing the Household model for a wealth-management rollout? Sapota's Salesforce team, certified on Financial Services Cloud Accredited Professional (AP-208), runs Household architecture and CDS configuration on every wealth FSC engagement. Get in touch ->
See the Salesforce service page for our team and credentials.
