Every financial advisory firm I've worked with defines "household" slightly differently. Different rollup requirements. Different opinions about Person Accounts. Different edge cases they didn't mention until week three of the build.
The FSC household model looks clean in the documentation. In production, it gets complicated. Here's what I've learned from building it multiple times.
The Core Structure
A household in FSC is an Account record with a Household record type. Members are individual person records (Person Accounts or individual business Accounts) connected to the household through AccountAccountRelation records.
The key objects:
Account (Household record type) is where household-level data lives. Combined AUM, household address, shared financial goals, advisor assignment.
Account (Individual, or Person Account) represents each person. Name, contact info, individual financial details.
AccountAccountRelation__c is the junction connecting individuals to households. It carries the role (Primary, Spouse, Dependent, etc.) and a primary flag.
The relationship is many-to-many. One person can belong to multiple households. A business owner might be in a personal household and a business entity. One household has multiple members. The junction record defines how they're connected.
Person Accounts: Just Do It
This is the first decision, and it ripples through everything.
Person Accounts combine Account and Contact into one record per person. The alternative is keeping the standard Account/Contact separation with an "Individual" record type on Account.
My recommendation for financial advisory firms: use Person Accounts. FSC was designed around them. The out-of-the-box components, rollups, and relationship maps work better with Person Accounts. The Salesforce documentation recommends it. Every implementation guide assumes it.
The exception: if you're on an existing org that's deeply built on standard Account/Contact and migrating would mean reworking a ton of automation and integrations. In that case, the migration cost might not be worth it. But for greenfield implementations, Person Accounts. Every time.
Rollups: The Part That Takes Longer Than You Expect
Advisors care about household-level numbers. Total AUM across all members. Combined revenue. Number of accounts. These roll up from Financial Accounts through individuals to the household.
FSC has some out-of-the-box rollup fields. They're rarely enough. You'll build custom rollups, and here's how I think about the options:
DLRS or Flow-based rollups work for simple sum/count/min/max. Easy to configure. The limitation is performance at scale. A household with hundreds of Financial Account records rolling up through multiple relationship levels can hit governor limits during bulk operations. I've seen batch data loads grind to a halt because every record triggers a cascade of rollup recalculations.
Apex trigger rollups give you full control. Weighted averages, conditional sums, rollups spanning multiple object levels. The pattern: trigger on the child object, collect all affected household IDs in bulk, query once, calculate, update once. Consider Queueable for heavy recalculations so you're not blocking the transaction.
Nightly batch jobs recalculate everything on a schedule. You lose real-time accuracy. You gain predictable performance and simpler error handling. For some firms that's the right trade.
What I usually recommend: real-time Apex triggers for the rollup fields advisors look at daily (total AUM, household revenue), plus a nightly batch as a reconciliation pass to catch any edge cases the triggers missed. The batch also serves as a safety net. If something weird happens during a bulk load and the real-time rollups get out of sync, the batch fixes it overnight.
Relationship Roles and the Primary Member
Every Account-Account Relationship needs a role: Primary Member, Spouse/Partner, Dependent, Beneficiary. FSC ships defaults. Most firms customize the list.
The primary designation drives a lot of downstream behavior. The primary member's advisor assignment often determines the household's advisor. Their address becomes the household address. Reporting filters to primary members by default.
Things I enforce:
One primary per household. FSC doesn't enforce this automatically. If two members both get the "Primary" role, rollups and display components can produce confusing results. A before-insert/before-update trigger on the relationship object that checks primary uniqueness is a small investment that prevents messy data later.
Explicit role change process. When the primary member changes (death, divorce, reassignment), the cascade can be significant: household name, advisor assignment, address, communication preferences. I build this as a deliberate process with admin tooling or a Screen Flow, not something that happens implicitly through a field edit. The number of things that need to update is easy to underestimate.
Active vs. historical membership. Dependents who turn 18 might get their own household. Ex-spouses need to be disassociated. Reporting queries need to filter on relationship status, not just relationship existence. I've seen dashboards double-count AUM because inactive household members still had relationship records.
The Financial Account Layer
Below households and individuals sits FinServ__FinancialAccount__c. Investment accounts, bank accounts, insurance policies.
The data model hierarchy: Household Account > Individual Account (via relationship junction) > Financial Account (via lookup).
That three-level hierarchy is where rollup logic gets hairy. You're rolling up Financial Account balances to the individual, then individual totals to the household. Triggers at both levels need to fire in the right order.
A pattern that simplifies things: put a direct lookup from Financial Account to the household Account in addition to the individual lookup. Yes, it's denormalized. But it gives you a two-level rollup path for household totals without traversing the junction. I keep it in sync with a trigger that copies the household ID from the individual's primary household whenever a Financial Account is created or reassigned.
The reporting benefit alone is worth it. Instead of joining through the junction to get household-level Financial Account data, you have a direct relationship. Your report types get simpler and your queries get faster.
The Stuff That'll Bite You
Household splitting. Divorce. Adult children leaving. Partnership dissolution. Your model needs to support cleanly moving individuals and their Financial Accounts from one household to another without losing history. I build this as documented admin tooling with a Screen Flow. Don't leave it to advisors manually editing relationship records. They'll forget a step and break a rollup.
Over-relying on OOB components. FSC's Relationship Map and household summary components are decent starting points but rarely match a firm's actual needs. Plan for custom LWC work. The household view your advisors want is almost always custom.
Data migration. This one burns people. Legacy system household data is almost always messy. Inconsistent name formats, duplicate individuals, conflicting addresses. The household model amplifies data quality issues because bad relationships propagate through rollups and views. Budget real time for cleanup and dedup before loading into FSC. If you don't, you'll spend twice as long fixing it post-migration.
The "what is a household?" conversation. Different people at the same firm will define it differently. Some mean immediate family. Some include business entities. Some include trusts. Get this locked down before you build anything. It affects record types, roles, rollup scope, and reporting. I usually force this conversation in the first week because everything downstream depends on it.
What Clean Looks Like
A solid FSC household implementation: Person Accounts for individuals, Household Accounts with a clear record type, enforced roles with primary designation, real-time rollups on key metrics backed by a nightly batch, a direct household lookup on Financial Accounts, explicit processes for household creation and splitting, and custom LWC for the views advisors actually use.
The data model isn't complicated. The complexity is in the business rules and in keeping the data clean as households change over time. Get the foundation right and those rules are straightforward.
Working on an FSC implementation? Let's talk.