FSC Data Model
Activate this skill when a practitioner needs to understand, design, or query the Financial Services Cloud (FSC) data model — covering the managed-package deployment with FinServ__ namespace objects and the platform-native Core FSC deployment using standard objects with no namespace. The skill covers the full object hierarchy from financial accounts through household relationships to rollup aggregation.
Before Starting
Gather this context before working on anything in this domain:
- Deployment type: Is the org using managed-package FSC (check Setup > Installed Packages for "Financial Services Cloud" or "Salesforce Industries") or Core FSC (platform-native, standard objects, no
FinServ__ prefix)? This determines every object name and SOQL query used.
- Person Accounts: Is Person Accounts enabled? FSC relies on Person Accounts to represent individual clients. Without it, the household and client relationship model does not work as documented.
- Rollup awareness: Practitioners assume native Salesforce roll-up summary fields aggregate financial data to household accounts. They do not. FSC uses its own async rollup engine configured in FSC Admin settings.
- Core FSC vs managed-package cutover: Orgs that went live before Winter '23 are almost certainly on managed-package FSC. New orgs provisioned after Winter '23 should evaluate Core FSC before defaulting to managed-package.
Core Concepts
Managed-Package FSC vs. Core FSC
FSC was originally delivered as a managed package under the FinServ__ namespace. Every custom object, field, and relationship carries that prefix: FinServ__FinancialAccount__c, FinServ__FinancialHolding__c, etc. Starting with Winter '23, Salesforce began shipping a platform-native version called Core FSC. Core FSC uses standard (no-namespace) objects: FinancialAccount, FinancialHolding, FinancialGoal. Core FSC eliminates package upgrade dependencies and gives full Metadata API control, but it is a different deployment architecture that cannot be retrofitted onto an existing managed-package org without migration work.
Choosing between them:
- New org with no existing FSC deployment → evaluate Core FSC as the default.
- Existing org already running managed-package FSC → stay on managed-package; a data and metadata migration to Core FSC is a large project.
- Hybrid or ISV package dependencies → managed-package may be required.
Key FSC Objects
| Object (managed-package) | Object (Core FSC) | Purpose |
|---|
FinServ__FinancialAccount__c | FinancialAccount | Represents a bank account, investment account, loan, or policy |
FinServ__FinancialAccountRole__c | FinancialAccountParty | Links a Contact or Account to a FinancialAccount with an ownership/role type |
FinServ__FinancialHolding__c | FinancialHolding | Represents individual securities, positions, or assets held inside a FinancialAccount |
FinServ__AssetsAndLiabilities__c | AssetsAndLiabilities | Standalone asset or liability record linked to a client or household |
FinServ__ContactContactRelation__c | Standard ContactContactRelation | Peer relationship between two contacts (e.g., spouses, dependents) |
FinServ__AccountAccountRelation__c | Standard AccountAccountRelation | Relationship between two accounts (e.g., subsidiary, group hierarchy) |
FinServ__FinancialGoal__c | FinancialGoal | Client financial goal with target amount, timeline, and progress tracking |
FinServ__LifeEvent__c | LifeEvent | Tracks life events (retirement, marriage, home purchase) tied to a contact |
Financial Account Ownership Model
Managed-package: FinServ__FinancialAccount__c has two hardcoded ownership lookups — FinServ__PrimaryOwner__c (required) and FinServ__JointOwner__c (optional). Only two owners are supported without custom workarounds.
Core FSC: The FinancialAccountParty junction object replaces the two-lookup pattern. It supports unlimited owners with named roles (Primary Owner, Joint Owner, Beneficiary, Power of Attorney, etc.). This is a significant architectural advantage for complex ownership scenarios such as trusts or investment partnerships.
Household Relationship Model
FSC models clients and households using standard Salesforce junction objects:
AccountContactRelation (ACR) — links a Contact (individual client) to an Account (the household). The Roles field on ACR carries the FSC-specific role (e.g., "Member", "Primary Member").AccountAccountRelation — links two Accounts. Used when a household account is part of a larger financial group or when corporate account hierarchies need lateral relationships.
The household Account record is typically a Business Account with RecordType = "Household." The individual clients are Person Account records linked to the household via ACR. This is distinct from the NPSP household model, which uses a separate npe01__OOHousehold__c object or Household Account without Person Accounts.
FSC Rollup Framework
FSC aggregates financial data (total assets, total liabilities, net worth) to the household Account using its own async rollup engine — not Salesforce native roll-up summary fields. The rollup engine is configured in FSC Admin Settings under "Rollup Configuration." Key behaviors:
- Rollups run asynchronously via a scheduled or triggered batch process.
- Rollup values are written to fields on the household Account (e.g.,
FinServ__TotalAssets__c, FinServ__TotalLiabilities__c).
- Creating or updating a financial account record does not immediately update the household total — the rollup batch must run.
- In Core FSC, rollup configuration moves to Industries Common Resources rollup framework settings.
- Do not create native roll-up summary fields on the Account object expecting them to aggregate FSC financial data — they have no relationship to the FSC rollup engine.
Common Patterns
Pattern: Querying a Client's Financial Portfolio
When to use: Any time you need to retrieve the financial accounts and holdings associated with a specific client contact.
How it works (managed-package):
-- Get all financial accounts where a contact is primary owner
SELECT Id, Name, FinServ__FinancialAccountType__c, FinServ__Balance__c,
FinServ__PrimaryOwner__r.Name
FROM FinServ__FinancialAccount__c
WHERE FinServ__PrimaryOwner__c = :contactId
-- Get holdings inside those accounts
SELECT Id, Name, FinServ__Shares__c, FinServ__Price__c, FinServ__FinancialAccount__r.Name
FROM FinServ__FinancialHolding__c
WHERE FinServ__FinancialAccount__r.FinServ__PrimaryOwner__c = :contactId
How it works (Core FSC):
-- Get financial accounts via FinancialAccountParty junction
SELECT FinancialAccount.Id, FinancialAccount.Name, FinancialAccount.Balance,
Role
FROM FinancialAccountParty
WHERE RelatedPerson.Id = :contactId
-- Get holdings
SELECT Id, Name, Quantity, Price, FinancialAccountId
FROM FinancialHolding
WHERE FinancialAccount.Id IN (
SELECT FinancialAccountId FROM FinancialAccountParty WHERE RelatedPersonId = :contactId
)
Why not the alternative: Querying directly on FinancialAccount without the party junction in Core FSC misses joint owners and named roles. In managed-package, querying only PrimaryOwner__c misses joint accounts.
Pattern: Household Financial Summary via ACR
When to use: You need to display aggregated financial data for a household and all its member contacts.
How it works:
-- Find all contacts in a household via AccountContactRelation
SELECT ContactId, Contact.Name, Roles
FROM AccountContactRelation
WHERE AccountId = :householdAccountId AND IsActive = TRUE
-- Read rollup values from the household Account (managed-package)
SELECT Id, Name, FinServ__TotalAssets__c, FinServ__TotalLiabilities__c,
FinServ__NetWorth__c
FROM Account
WHERE Id = :householdAccountId
Why not the alternative: Do not aggregate financial account balances in SOQL at query time for household totals in production — this does not scale for households with many accounts. Read the pre-computed rollup fields on the Account and ensure rollup batches are scheduled.
Decision Guidance
| Situation | Recommended Approach | Reason |
|---|
| New org, no existing FSC data | Core FSC (platform-native) | No namespace overhead, unlimited FinancialAccountParty owners, full Metadata API control |
| Existing org on managed-package FSC | Stay on managed-package | Migration to Core FSC requires full data and metadata migration; no in-place upgrade path |
| Complex multi-owner accounts (trusts, partnerships) | Core FSC FinancialAccountParty | Managed-package is limited to PrimaryOwner + JointOwner only |
| ISV or AppExchange package depends on FinServ__ objects | Managed-package | Third-party packages built against managed-package namespace; Core FSC incompatible |
| Household financial totals appear stale after data load | Trigger FSC rollup batch via Admin Settings | FSC rollups are async; totals do not update synchronously on record save |
| Need to query financial accounts across all owners | FinancialAccountParty (Core) or both owner lookups (managed) | Managed-package PrimaryOwner__c alone misses joint accounts |
Recommended Workflow
- Identify the FSC deployment type — check Setup > Installed Packages. If "Financial Services Cloud" or "Salesforce Industries" is listed as a managed package, all object names require the
FinServ__ prefix. If no such package is found but FSC features are available, the org is on Core FSC.
- Map the relevant object graph — identify which objects are in scope: start from
FinancialAccount (or FinServ__FinancialAccount__c), trace ownership via FinancialAccountParty or PrimaryOwner__c/JointOwner__c, and identify the household Account linked via AccountContactRelation.
- Verify rollup configuration — for any task that reads household financial totals, confirm the FSC rollup batch is scheduled and the rollup configuration covers the account types involved. Do not assume totals are current.
- Write namespace-correct SOQL — prefix all custom object and field API names with
FinServ__ in managed-package orgs; use no prefix in Core FSC orgs. Test queries in Developer Console or Data Loader against the actual org before finalizing.
- Validate ownership completeness — for multi-owner scenarios, query
FinancialAccountParty (Core FSC) or both PrimaryOwner__c and JointOwner__c (managed-package) to ensure all owners are captured; a query on PrimaryOwner__c alone misses joint account holders.
Review Checklist
Salesforce-Specific Gotchas
-
Native ROLLUP summary fields do not aggregate FSC financial data — Salesforce roll-up summary fields on the Account object have no knowledge of the FSC rollup engine. Adding a native ROLLUP summary field to aggregate FinServ__Balance__c values will not work because FinServ__FinancialAccount__c is not a detail of Account in the standard master-detail sense for ROLLUP purposes. FSC maintains its own batch-computed rollup fields.
-
FinServ__ namespace is absent in Core FSC orgs — Code or queries written against managed-package FSC will fail entirely in a Core FSC org. The object FinServ__FinancialAccount__c does not exist; the equivalent is FinancialAccount. Always confirm org type before writing any FSC SOQL, Apex, or Flow references.
-
Managed-package FinancialAccountRole limits ownership to two parties — FinServ__FinancialAccountRole__c exists in managed-package FSC but the primary and joint ownership model is enforced through lookup fields directly on FinServ__FinancialAccount__c (FinServ__PrimaryOwner__c, FinServ__JointOwner__c). Adding a third owner requires a custom junction object or workaround. Core FSC's FinancialAccountParty removes this constraint entirely.
Output Artifacts
| Artifact | Description |
|---|
| Object relationship map | Diagram or table of FSC objects with namespace-correct names, relationship types, and cardinality |
| SOQL query patterns | Namespace-correct SOQL for common financial data access patterns (portfolio, household summary, ownership) |
| Rollup configuration checklist | Steps to verify FSC rollup batch schedule and rollup configuration for household financial totals |
Related Skills
data/person-accounts — FSC relies on Person Accounts for individual client representation; see this skill for Person Account setup and implicationsadmin/financial-account-setup — FSC Admin Settings configuration for rollups, account types, and financial account record type setuparchitect/fsc-architecture-patterns — higher-level architecture decisions including managed-package vs. Core FSC selection, sharing model, and integration patterns