Ask any banker who has worked with FSC’s managed package what frustrates them most about how it models client relationships, and household management is near the top of the list. Not because the concept is wrong — grouping clients into households, rolling up their financial data, and giving relationship managers a unified view is exactly what a banking CRM should do. But because the implementation has always felt like a workaround for relationship complexity that financial institutions actually live with every day.
The managed package household model was built for a relatively narrow definition of a household: a family, modeled as an Account record with a specific record type, with individual members linked through standard relationship objects. For a wealth management firm managing high-net-worth families with straightforward account structures, it works reasonably well. For a bank or lending institution managing the full spectrum of retail and commercial relationships — families, businesses, trusts, estates, partnerships, and the web of connections between them — it consistently falls short.
FSC Core’s Party Relationship Group is not a cosmetic improvement on the household model. It is a fundamental rethinking of how relationship grouping works in a financial services CRM — and for banking and lending institutions, it represents one of the most impactful practical upgrades in the entire FSC Core architecture.
Why the Record Type Model Was Always a Compromise
The managed package’s household is an Account record with a Household record type. This design choice carries a set of structural constraints that become apparent as soon as you encounter relationship complexity beyond the simple nuclear family model.
The Record Type Ceiling
In Salesforce, a record type defines a category of record on a given object — and an Account can only have one record type at a time. This means that a household Account is fundamentally distinct from a person Account or a business Account in the data model. You cannot have a record that is simultaneously a household and a business entity. You cannot represent a trust as both a legal entity and a household anchor. You cannot model a multi-generational family office that spans individual accounts, a family LLC, and a charitable foundation as a single coherent group.
These are not edge cases. They are the everyday reality of relationship banking, private banking, commercial banking, and small business lending. The record type ceiling forced institutions into one of three uncomfortable positions: accepting a simplified model that did not reflect reality, building custom objects and relationships to fill the gaps, or maintaining separate relationship maps outside Salesforce entirely.
The Rollup and Aggregation Problem
Because household data was modeled on the Account object with record types, aggregating financial data across a household required rollup configurations that were tightly coupled to the managed package’s rollup-by-lookup mechanism. Relationship managers who wanted to see the total deposit balance, total loan exposure, or net worth of a household group were dependent on nightly batch rollup processes — with all the latency and performance limitations that implied.
For a relationship manager preparing for a client meeting at 8 AM based on data that was last refreshed the previous evening, that lag is not trivial. It means the numbers on screen may not reflect a large deposit made yesterday afternoon, a loan payoff processed that morning, or a balance transfer that changed the household’s overall picture.
The Visibility Gap
Perhaps most practically limiting: the record type household model made it structurally difficult to surface the full relationship picture in a single view. Relationship managers often had to navigate across multiple Account records — the household, each individual member, each associated business entity — to assemble a complete understanding of a client group’s total relationship with the bank. That navigation cost is real, and it accumulates across hundreds of client interactions every day.
The best relationship bankers have always carried a mental model of their clients that is richer than what their CRM could display. FSC Core’s Party Relationship Group closes that gap.
The Party Relationship Group: A Better Mental Model
The Party Relationship Group (PRG) is a dedicated object in FSC Core designed specifically to represent relationship groups of any kind. It is not an Account record type. It is not a workaround. It is a first-class Salesforce object that exists to hold, organize, and surface relationship group information — separate from the accounts and contacts that belong to it.
This distinction matters architecturally because it removes the fundamental constraint of the record type model: the need for a group to be the same kind of thing as its members. A Party Relationship Group is its own thing — a container that references members, rather than a member that doubles as a container.
How the PRG Works
When a relationship manager creates a household or relationship group in FSC Core, they are creating a Party Relationship Group record. That PRG record holds the group-level information: the group name, the group type, any group-level notes or attributes, and the aggregated financial summary data.
Members are linked to the PRG through relationship records that define each member’s role in the group. Those members can be person accounts, business accounts, trusts, or any other Account record in the org — regardless of record type. The PRG holds them together without requiring them to conform to a single entity type.
The household creation wizard in FSC Core walks users through the setup process step by step: create the PRG, add members, assign relationship roles, link financial accounts, and configure the relationship map view. The result is a structured, navigable relationship group that reflects the actual composition of the client relationship.
Relationship Roles: Making the Implicit Explicit
One of the most operationally valuable aspects of the PRG model is the ability to assign explicit relationship roles to each group member. In the managed package, the relationship between household members was largely implicit — visible through the account-contact relationship structure, but not labeled or queryable in a structured way.
In FSC Core, every PRG member has a defined role: Primary Member, Spouse or Partner, Dependent, Business Owner, Trustee, Beneficiary, Authorized Representative, or custom roles your institution defines. Those roles are data — structured, reportable, and available to automation, AI, and downstream reporting in ways that implicit relationships never were.
For a compliance officer building a KYC workflow, having explicit beneficial ownership roles as structured data is meaningful. For an Agentforce agent surfacing relationship context to a banker before a client call, having queryable role data is what makes the prompt relevant and accurate. For a marketing team building segmentation models around relationship composition, structured roles are the foundation of meaningful targeting.
|
Banking Scenario: Retail Banking — The Multi-Generational Family |
|
A retail banking family has four members across two generations: a retired couple, their adult son who runs a small business, and their daughter who recently started college. The family has joint checking and savings accounts, individual accounts for each member, a small business operating account for the son’s LLC, and a 529 education savings account for the daughter. Managed Package: The household Account contains the couple. The son’s LLC is a separate business Account with no native link to the household. The daughter’s 529 requires a custom solution or is tracked separately. The relationship manager has no single view of the full family relationship. FSC Core: A single Party Relationship Group links all entities: both parents (Primary Members), the son (Household Member, linked to his LLC as an associated entity), and the daughter (Household Member). All accounts — joint, individual, business, and education — are associated with the group. Balance rollups aggregate across all members. The relationship manager sees the complete family picture in one view, with each member’s role and associated accounts clearly displayed. |
|
Banking Scenario: Commercial Banking — The Owner-Managed Business |
|
A commercial banking client is a regional contractor. She personally guarantees the business’s line of credit, holds a personal mortgage with the bank, and has a joint savings account with her spouse. Her business has three operating accounts, a commercial vehicle loan, and a construction equipment lease. Managed Package: The individual and the business are separate Account records. Linking them requires custom Account-Account relationships with no native rollup capability. The relationship manager must navigate between two unconnected record views to understand the total exposure and total relationship value. FSC Core: A Party Relationship Group represents the combined personal and commercial relationship. The individual is the Primary Member; the business is a linked entity with an Owner role. Personal guarantee relationships are captured through Financial Account Party records. Total deposits, total loan exposure, and net relationship value roll up across both the personal and business accounts in a single group summary. The relationship manager prepares for every client interaction with a complete picture. |
|
Lending Scenario: Trust and Estate — Complex Ownership Structures |
|
A private banking client has established a revocable living trust that holds his primary residence and investment accounts. He is the trustee and primary beneficiary during his lifetime. His two adult children are contingent beneficiaries. His spouse has power of attorney. Managed Package: The trust is a separate Account record. The relationship between the trust, the individual, his spouse, and his children requires custom relationship objects. There is no native way to model trustee, beneficiary, and power of attorney roles as structured data. Compliance and estate planning workflows depend on manual tracking outside the CRM. FSC Core: A Party Relationship Group encompasses all parties: the client (Primary Member and Trustee), the spouse (Power of Attorney), and the children (Contingent Beneficiaries). Each role is defined as a structured relationship record. Financial accounts held by the trust are linked to the group. Estate planning workflows, compliance reviews, and advisor-to-client conversations are all grounded in accurate, structured data that reflects the actual legal and financial reality of the relationship. |
PRG Capabilities: What FSC Core Delivers
The table below summarizes the key capabilities of the Party Relationship Group model and what each one means for banking and lending institutions:
|
Capability |
What It Means for Banking & Lending |
|
Multi-entity group composition |
Include person accounts, business accounts, trusts, and other entity types within a single relationship group — without record type constraints. |
|
Explicit member role definition |
Each group member carries a defined relationship role (e.g., Primary Member, Spouse, Business Owner, Trustee) that is structured, reportable, and queryable. |
|
Cross-entity balance rollups |
Aggregate balances across all members and accounts in a group using Summary Rollups — giving a true picture of total relationship value. |
|
Guided household wizard |
A built-in creation wizard walks users through setting up a Party Relationship Group, adding members, assigning roles, and linking financial accounts — no custom UI required. |
|
Flexible group naming |
Groups can be named and categorized to reflect their purpose: Household, Family Office, Commercial Group, Trust Group, or custom categories your institution defines. |
|
Relationship map visualization |
The updated Relationship Map component in FSC Core displays Party Relationship Group members and their connections in a visual, interactive layout. |
|
Integration with Agentforce |
Party Relationship Group data is accessible to Agentforce agents natively, enabling AI-assisted relationship insights and proactive banker prompts built on the full group context. |
The Relationship Manager Experience: What Changes Day to Day
It is worth pausing on the day-to-day impact of this change, because the PRG model is not just an architectural improvement — it is a user experience improvement for the bankers and relationship managers who live in Salesforce every day.
In the managed package model, a relationship manager preparing for a client meeting with a complex client relationship — one that spans personal accounts, business accounts, and trust entities — faced a navigation challenge before every interaction. They had to mentally assemble the full picture from multiple disconnected records, cross-referencing account lists, manually totaling balances, and relying on personal knowledge to fill the gaps that the CRM could not surface.
In FSC Core with a well-configured Party Relationship Group, that assembly happens automatically. The relationship manager opens the PRG record and sees: all members, all accounts, all relationship roles, aggregated balances, recent activity across the full group, and — as Agentforce capabilities mature — AI-surfaced insights about the relationship. The mental work that used to happen before the meeting now happens in the platform.
This is not a marginal productivity gain. Research on high-performing relationship bankers consistently shows that the quality of pre-meeting preparation is one of the strongest predictors of client satisfaction, cross-sell success, and relationship retention. Giving relationship managers a platform that makes excellent preparation easy — rather than requiring heroic effort — compounds over time into a genuine competitive advantage.
A relationship manager who walks into every client conversation with a complete, accurate picture of the full relationship is not just more productive. They are genuinely better at their job.
What This Means for Institutions on the Managed Package
If your institution has invested in building household management workflows on the managed package — custom rollup configurations, page layouts tuned for relationship manager workflows, integrations that populate household data from core banking systems — the move to the Party Relationship Group model requires careful planning. The data migration from household Account records to PRG records is a meaningful workstream, not a trivial lift.
But the right framing for that work is not “migration cost.” It is “the one-time investment required to move from a model that constrains your relationship management to one that enables it.” Institutions that have done this migration consistently report that the PRG model surfaces relationship complexity that the household model was silently hiding — and that the effort of building accurate PRG structures for existing clients is an opportunity to clean and enrich relationship data that had accumulated inaccuracies over years.
Post 9 in this series provides a practical migration framework that includes specific guidance on the household-to-PRG transition — how to assess your current household data quality, how to sequence the migration, and how to use the transition as an opportunity to build a more complete and accurate client relationship model.
For now, the strategic point is this: the Party Relationship Group is what the FSC household model was always trying to be. It delivers on the promise of whole-relationship banking in a way that the record type model never could. For institutions that compete on the quality of their client relationships, that is not a future consideration. It is a present-day competitive imperative.
PREVIOUS IN THE SERIES
Post 3: The Data Model Revolution — From Financial Accounts to Financial Account Parties
NEXT IN THE SERIES
Post 5: Saying Goodbye to Batch Rollup Lag — Why Core’s Performance Architecture Changes Everything
About This Series
“Building the Future of Financial Services on Salesforce’s Native Platform” is a 10-part thought leadership series exploring why FSC Core represents the strategic imperative for financial services and banking institutions on Salesforce. Posts publish weekly.
