Financial Account & Goal Management in Salesforce FSC

Every conversation a financial advisor, banker, or insurance agent has with a client ultimately comes back to the same question: what does this person own, owe, and want? Financial Services Cloud answers that question with two foundational pieces of its data model — the Financial Account object that captures everything a client owns or owes, and the Financial Goal object that captures what they’re working toward.

Around those two objects, FSC layers a network of roles, holdings, transactions, and rollups that turn raw account data into household-level intelligence. Get the mechanics right and you have a 360° view of a client’s financial life. Get them wrong and balances vanish from rollups, goals don’t surface on dashboards, and advisors lose trust in the data.

What It Is and Why It Matters

Financial Account & Goal Management is the FSC capability that models a client’s complete financial picture inside Salesforce. It captures every checking account, brokerage account, mortgage, credit card, and insurance policy as a Financial Account, then ties each account to one or more people through Financial Account Roles. Financial Goals layer on top to capture client objectives — retirement, college funding, a home purchase — and track progress toward them.

Where standard Salesforce gives you the Account and Contact objects, FSC adds an entire financial-services product layer on top. The result: an advisor can open Rachel Adams’s record and instantly see her investment portfolio, her primary checking, her life insurance policy, her retirement goal, and the same view rolled up across her husband Nigel’s accounts at the household level.

The Financial Account Object: Core Architecture

The Financial Account is FSC’s universal product container. Whether you’re modeling a checking account, a brokerage portfolio, a mortgage, or an insurance policy, it lives on the same object — distinguished by record type and by the role its owners play.

This single-object design is deliberate. Holding every product on one object simplifies rollups to the household, makes net-worth calculations straightforward, and lets you record both products held with your institution and “held away” products at other institutions (toggled by a flag on the record).

Two flavors of the same object

FSC ships Financial Account in two technically distinct forms — the managed-package custom object and the standard platform object — and an admin’s first job is usually to know which one their org uses:

Record Types: Predefined Account Categories

Out of the box, FSC ships several record types on the Financial Account object — each with its own page layout, field set, and dedicated Lightning component on the Account page. The standard record types cover the most common product categories in retail banking and wealth management:

Admins can extend this list — adding a Safe Deposit Box or Blockchain Account record type, for example. But unlike standard Salesforce customization, simply adding a new record type isn’t enough. FSC’s Financial Account components rely on field sets to control which fields display for each record type, so a complete extension involves creating the record type, page layout, custom fields, and the matching field set, plus adjusting the Lightning component on the Account layout to render it.

Financial Account Roles: The Ownership Junction

A Financial Account on its own has no owner. The relationship between people and accounts is modeled through a junction object — FinServ__FinancialAccountRole__c in the managed package or FinancialAccountParty in FSC Core.

Every Financial Account must have at least one active role with the type Primary Owner. The Primary Owner determines which client’s totals the account contributes to and, when that client has a primary group, which household the account belongs to.

Role types on a Financial Account

The role object supports multiple participant types per account. The most common are:

Per Salesforce’s own documentation, the Primary Owner record on a Financial Account is created automatically in the same junction object when the account is created. Other role records — joint owners, beneficiaries, trustees — must be added manually or through automation.

Why ownership matters for rollups

Ownership rules in FSC are precise. When Vivian and Lucy are joint owners of an account, the full balance shows up in both Vivian’s profile and Lucy’s profile individually — but if they share a household, the balance is counted only once at the household level. When Vivian and a trust co-own an account, the primary owner — not the joint owner — determines whether the balance lands in Vivian’s rollup or in the trust’s rollup. That single attribute, captured in one role record, drives the entire reporting hierarchy.

Managed Package vs. FSC Core: Two Data Models

Salesforce launched FSC in 2016 as a managed package built on top of standard Salesforce. Starting in 2019, the company began rebuilding FSC’s most popular features as native platform capabilities — a transition Salesforce now refers to as FSC Core. Today, both models coexist, and admins can find themselves working with either.

Holdings, Securities, and Transactions

For investment accounts, FSC adds a layer of detail beneath the Financial Account: individual holdings, the securities they reference, and the transactions that flow through the account.

Financial Holdings

A Financial Holding represents a single position within an investment account — for example, 1,000 shares of CRM (Salesforce). Each holding stores the security symbol, share count, price, market value, and gain/loss. Holdings are child records of a Financial Account, so a single brokerage account can have dozens of holdings rolling up to a total portfolio value.

Securities

A Security is the tradable instrument behind a holding — a stock, bond, mutual fund, or ETF. Securities are referenced by holdings rather than owned by clients; the same security record can be linked to many holdings across many investment accounts. When loading data, Salesforce recommends loading securities before holdings so the reference data exists when the holding is created.

Financial Account Transactions

The Financial Account Transaction object captures the activity history on an account — deposits, withdrawals, transfers, fees, and interest payments. Transactions are surfaced on the Financial Account page and feed components like the Financial Accounts Summary, giving service agents a consolidated view of recent activity without leaving the client’s profile.

Financial Goals: Tracking Client Objectives

Financial Goals capture what a client is saving toward — a retirement target, a college fund, a home down payment, a charitable bequest. Each goal carries a target amount, a target date, and a current actual value, letting advisors quickly see how close a client is to hitting their objective.

Standard vs. managed-package goals

Like the Financial Account, Financial Goal exists in two flavors. The managed package ships FinServ__FinancialGoal__c as a custom object. The standard FinancialGoal object was introduced in API version 59.0 (Winter ’24) and represents a financial goal for a Person Account.

Both objects model the same concept — a client objective tied to an Account — but they cannot be mixed in the same data flow. Pick the model that matches your overall FSC architecture (managed package or FSC Core) and use it consistently.

Goal scope: client or household

A goal can be tied to a single client or to a household. A household goal — “Adams Family — Retirement Reserve” — is just a Financial Goal whose primary owner is the household account rather than the individual. This lets families track joint objectives like a college fund or a vacation home down payment without duplicating records.

Record Rollups to Households and Groups

Record rollups are the mechanism FSC uses to aggregate child records — Financial Accounts, Goals, Assets and Liabilities, and others — up to the client and then to the household level. Done well, they turn a flat data model into the consolidated, household-level view that financial professionals rely on.

How the rollup is computed

The path runs in two segments. First, every Financial Account rolls up to its Primary Owner — the client whose role record is marked Primary Owner. Then, if that client has a primary group designated on their Account Contact Relationship record, the account is automatically stamped with the household.

Client-level rollups happen by default — no setup required. Group-level rollups must be explicitly enabled, and only members whose primary group is the target household have their data rolled up. This is one of the most common sources of “missing balance” tickets in FSC.

The Rollups field on Account Contact Relationship

Group-level rollups are governed by the Rollups multi-select picklist on the Account Contact Relationship object. Each value in this field controls one category of data that rolls up to the group level:

• Financial Accounts
• Financial Goals
• Events
• Tasks
• Assets and Liabilities
• Referrals

To add new categories — Cases, Opportunities, Insurance Policies, Claims — admins extend this picklist with additional values. Without the corresponding picklist value selected on a member’s relationship record, that category will not appear at the group level.

Rollup By Lookup, DPE, and Financial Summary Rollup

Beyond record rollups, FSC ships a more powerful aggregation engine — Rollup By Lookup (RBL) — that aggregates numeric data from child records up to the parent via configurable rules. RBL is what calculates totals like “Total Financial Accounts” or “Total Investments” on a client or household account.

Where RBL applies

RBL rules are available only for a specific set of objects. Per Salesforce documentation, those objects are:

RBL rules trigger when the source record is created or when the specific field being measured changes. For example, updating the balance on a checking account triggers the RBL rule to recompute the “Total Financial Accounts” value on both the primary owner’s Account and the primary group.

The Data Processing Engine (DPE)

The Data Processing Engine is Salesforce’s enhanced framework for high-performance RBL calculations. DPE uses the calculation power of CRM Analytics to process rollup rules faster and at greater scale than the legacy framework. It is the recommended backbone for new rollup configurations in FSC.

DPE comes standard with FSC in Enterprise, Unlimited, and Performance editions. It also powers rollups in Manufacturing Cloud, Loyalty Management, Net Zero Cloud, Rebate Management, and other industry clouds — making it useful platform knowledge well beyond FSC alone.

Financial Summary Rollup (FSC Core)

For orgs on FSC Core, Salesforce introduced a separate, newer rollup mechanism: Financial Summary Rollup. This feature uses the standard AccountFinancialSummary object — introduced in API version 62.0 (Winter ’25) — to store aggregated financial details for an account or party relationship group. It’s only available when Financial Summary Rollup settings are enabled in Setup.

Financial Summary Rollup is the FSC Core equivalent of the managed-package RBL approach. It computes summaries asynchronously and writes them to dedicated summary records rather than fields on the parent Account.

Creating Financial Accounts and Goals: User Experience

Day-to-day, end users rarely interact with the raw objects. FSC ships purpose-built Lightning components that surface accounts and goals contextually on Person Account and Household pages.

From the client profile

1. Open the client’s Account (Person Account or Individual) record.
2. Navigate to the Financial Accounts tab or related component on the Lightning page.
3. Choose the appropriate record type — Investment, Checking, Loan, Insurance, etc.
4. Enter the account details. The Primary Owner is set to the client automatically.
5. Save. If the client has a primary group, the account is automatically stamped with that household and contributes to its rollups.

From the household

Opening the Household account record and navigating to Financial Accounts surfaces every account owned by every primary member of the household — provided each member has “Financial Accounts” selected in the Rollups field of their Account Contact Relationship. From here, advisors can drill into any individual account or view consolidated totals at the household level.

Creating a Financial Goal

Goals are created from the client’s profile (for individual goals) or from the household record (for shared goals). The flow captures target value, target date, goal type, and primary owner. If the goal’s owner has a primary group and that group has “Financial Goals” selected in its Rollups picklist, the goal also appears on the household record.