Relationship Group Member
A Relationship Group Member in Salesforce Financial Services Cloud (FSC) is an individual account or contact record associated with a Relationship Group (also called a Household), with attributes defining the member's role and contribution within that grouping.
Definition
A Relationship Group Member in Salesforce Financial Services Cloud (FSC) is an individual account or contact record associated with a Relationship Group (also called a Household), with attributes defining the member's role and contribution within that grouping. The model lets a wealth advisor, banker, or insurance agent view a single client family as a coherent unit rather than as scattered individual records. Members can be the primary client, the spouse, dependents, related business entities, or anyone else whose financial life is connected to the household.
Relationship Group Members are the building blocks that turn a list of unrelated Contact records into a meaningful family or business relationship. Each Member record links a specific person or entity to a specific Group with metadata about their role (Primary Member, Spouse, Child, Parent, Business Owner) and any specific permissions or rights within the group (decision authority, beneficiary status, joint ownership). The pattern is essential for wealth management workflows where decisions are made at the household level rather than the individual level, even though the underlying compliance and reporting still happens at the individual level.
The Relationship Group Member data model
The Household concept and its purpose
Financial Services Cloud organizes individual clients into Relationship Groups (commonly called Households for retail wealth management or Trust Groups for institutional contexts). The Group is an Account record with the Relationship Group record type. Members are Contact records or Account records linked to the Group through the junction object Account Contact Relation or a custom relationship object. The Group provides a single anchor for viewing all financial activity across the family: accumulated assets, total revenue, joint goals, shared advisors. Without the Group concept, advisors must mentally aggregate across multiple records, which scales poorly with portfolio size.
Member roles and their meaning
Each Relationship Group Member carries a Role attribute that captures their relationship to the rest of the group: Primary Member (the lead client), Spouse, Child, Parent, Sibling, Business Partner, Trustee, Beneficiary, Power of Attorney. The role drives downstream behavior: which member's signature is required for certain decisions, who has access to which information, who appears on which reports. The role taxonomy is standard in FSC but can be customized for organizations with specific relationship types (multi-generational families, complex business structures, blended families). Documenting the role taxonomy and training advisors on it is essential to consistent data quality.
Privacy and the visibility model
Households have privacy implications. A spouse may not want their personal information visible to other family members through the household view; a parent may not want their financial activity visible to adult children. FSC supports per-member visibility controls so each Member can choose what information is visible at the household level. The advisor must respect these settings when reviewing household data and when generating reports. Mature wealth management programs train advisors on the privacy controls and audit compliance with the privacy settings periodically. Mishandling household privacy is a source of client complaints and, in some jurisdictions, regulatory liability.
Aggregation and rollup of financial data
Relationship Groups support rollup of financial data across members: total assets under management for the household, combined revenue, aggregated cash flow. The rollups are implemented through Apex triggers or Flow-based automation that maintains the household totals as individual member data changes. The aggregation lets the advisor see the household as a whole while still preserving the per-member granularity. For larger households (extended families, business groups), the rollup can include multiple levels of nesting, and the aggregation logic must handle this correctly. Many FSC implementations have custom rollup logic specific to the firm's product structure.
Membership changes and lifecycle
Households change over time: marriages add spouses, divorces remove them, children grow up and move out of their parents' household, business partnerships dissolve. The Member record supports lifecycle changes: adding a member, removing a member, changing a member's role, moving a member to a different household. Each change has implications for the financial data: assets that belonged to the household may now belong to a specific individual after a divorce. The data model handles these transitions through effective-date fields on the Member record. FSC implementations should document the household-change workflows so that advisors handle marriages, divorces, deaths, and family transitions consistently.
Compliance and regulatory reporting
Financial services regulation typically operates at the individual level even though wealth management operates at the household level. FATCA reporting is per individual; AML screening is per individual; KYC is per individual. The household aggregation in FSC supports advisor workflow but does not replace the per-individual compliance reporting. Implementations must maintain both views: the household view for advisor productivity and the individual view for compliance. Custom reports and integrations to compliance systems should reference the individual Member records, not the household total, to ensure regulatory accuracy.
Cross-household relationships
Some financial relationships span multiple households. A trust set up for the benefit of multiple family branches has members in different households who all share an interest. A business partnership has members who each belong to their own personal households but share interest in a joint entity. FSC supports cross-household relationships through additional relationship objects (Trustee, Beneficiary, Owner) that link members across groups. The complexity of these relationships grows quickly, and implementations should model them carefully during initial setup rather than retrofitting later. Wealth managers who serve ultra-high-net-worth families regularly hit these complex relationship structures and need a data model designed to express them.
Operational discipline around household data
Beyond the technical configuration, the operational discipline around household data is what determines whether the model produces useful advisor workflow or accumulates inconsistency over time. Three practices recur in wealth management programs that get this right. First, household reviews scheduled annually with each client family to confirm the membership is current: who is in the household, what their roles are, what privacy settings they want. The review catches lifecycle events (children leaving home, new spouses, deceased members) that may not have been recorded otherwise. Second, advisor coaching on consistent household structure: rather than each advisor creating households differently, the firm establishes a standard pattern for who counts as a household member, what roles to use, and how to handle edge cases (estranged spouses, multiple marriages, businesses owned by household members). Third, periodic data quality audits checking the household-to-member integrity: every Member belongs to a current household, every household has at least a Primary Member, rollups match the underlying member data. The combination of these three practices produces clean, useful household data over years; without them, the household model becomes noisy and undermines the advisor workflow it was meant to enable. Mature wealth programs treat household data quality as an ongoing operational priority, not a one-time setup task. The investment in this discipline distinguishes top-performing wealth management programs from mediocre ones in many ways beyond just the Salesforce configuration.
Configure Relationship Group Members in FSC
Setting up Relationship Group Members in Financial Services Cloud spans creating the Relationship Group, adding individual Members with roles, configuring rollups, and establishing the privacy controls. The walkthrough below covers the standard sequence for a typical wealth management household setup.
- Create the Relationship Group Account
From the Accounts tab, create a new Account with the Relationship Group record type. Enter the household name (typically the surname followed by Household, like Smith Household). Assign the primary advisor and any specialists. Save the record. Verify the household page layout shows the Members related list and the rollup fields for assets, revenue, and other aggregated metrics.
- Add Members with roles
From the Members related list, add each Contact or Account that belongs to the household. Set the Role for each Member: Primary Member for the lead client, Spouse for their partner, Child for dependents, and so on. Set the effective date if the relationship has a specific start. Save each Member record. The household page should now show the family structure with each role visible.
- Configure privacy and visibility
For each Member, configure the privacy settings: which information is visible at the household level versus restricted to specific individuals. Default settings work for most households; sensitive scenarios (children, complex families) require explicit configuration. Train the advisor on the privacy settings so they respect each Member's preferences when reviewing household data or generating reports.
- Validate rollups and reporting
Add sample financial data to each Member: investment accounts, insurance policies, banking relationships. Confirm the household-level rollup fields aggregate correctly. Test reports filtered by household and by individual to confirm both views work. Spot-check the privacy settings by impersonating a member to confirm they see only what they should. Iterate on the configuration based on what the validation reveals.
Required for the FSC-specific objects, record types, and features including Relationship Groups.
The parent Account record with the Relationship Group record type that anchors the household.
The role values that describe each member's relationship to the household, configured as picklist values or custom values.
The Apex triggers or Flow automation that maintains household-level rollup fields.
Per-member visibility configuration that respects each member's privacy preferences within the household.
- Compliance reporting is still per individual, not per household. The household view is for advisor productivity, not for regulatory submission.
- Household changes (divorce, death, marriage) have data implications that the standard model may not handle without custom logic.
- Privacy settings are easy to skip during initial setup. Skipping them creates household views that expose information members did not consent to share.
- Rollup logic for complex households (nested groups, cross-household relationships) often requires custom code. Plan for it during initial data model design.
- Cross-household relationships (trusts, partnerships, blended families) need explicit modeling. The default single-household structure does not handle them.
Trust & references
Straight from the source - Salesforce's reference material on Relationship Group Member.
- Financial Services Cloud OverviewSalesforce Help
- Relationship GroupsSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Relationship Group Member?
Q2. What roles might members have?
Q3. Why track member roles?
Discussion
Loading discussion…