Salesforce FSC AUM Rollups: How to Configure Total Assets Under Management in the New Data Model

SEO title: Salesforce FSC AUM Rollups Guide 2026: Configure Total Assets Under Management | Vantage Point
Meta description: Learn how to configure Total Assets Under Management in Salesforce Financial Services Cloud using Record Rollup Definitions, DPE, household groups, and business account rollups.
Suggested slug: blog/sf/salesforce-fsc-total-assets-under-management-aum-rollups-guide

Quick Answer

In the Salesforce Financial Services Cloud Standard/Core data model, teams should calculate Total Assets Under Management by using Record Rollup Definitions powered by Data Processing Engine, not by trying to recreate the legacy Account-level Total AUM field. The practical pattern is to define a clear AUM policy, roll up qualifying Financial Account values through Financial Account Party relationships, store the result on Party Relationship Groups for households and on Business Accounts or business-type groups for entities, and then display those values through record pages, reports, FlexCards, or analytics.

This matters because the new model gives teams more flexible household, business, ownership, and relationship modeling, but it also requires more deliberate design. If the rollup path, filters, or ownership attribution rules are unclear, AUM can be incomplete, duplicated, or inconsistent across advisor views and reporting.

TL;DR

What Is Total Assets Under Management in Salesforce Financial Services Cloud?

Total Assets Under Management in Salesforce Financial Services Cloud is the sum of qualifying financial account values attributed to a household, business, client, advisor, or relationship group. In wealth and financial services CRM operations, AUM usually represents the managed asset value that should inform service prioritization, segmentation, advisor coverage, and reporting.

In older Financial Services Cloud implementations, teams often relied on preconfigured rollup behavior and managed-package patterns around households and Accounts. In the newer Salesforce Financial Services Cloud Standard/Core data model, the same business outcome is still achievable, but the configuration approach changes.

Instead of assuming a single Total AUM field exists on Account for every use case, admins and architects should define the AUM logic intentionally across these objects and concepts:

• Financial Account for account or asset records.
• Financial Account Party for ownership, role, and attribution relationships.
• Party Relationship Group for households, business groups, trusts, and other relationship structures.
• Business Account when an entity-level AUM value is needed directly on Account.
• Record Rollup Definitions and Data Processing Engine for scalable cross-object aggregation.

For teams modernizing Financial Services Cloud, this is also a good moment to review broader Salesforce implementation and advisory, system integration and data migration, and CRM governance decisions.

Why Did the AUM Configuration Pattern Change in the New FSC Data Model?

The AUM configuration pattern changed because Salesforce Financial Services Cloud Standard/Core uses a more flexible relationship model than many legacy FSC implementations. The new model is designed to represent people, businesses, households, trusts, ownership roles, and relationships more explicitly.

That flexibility is valuable, but it also means AUM cannot always be treated as a simple direct rollup from child records to one Account. A household may contain multiple people. A financial account may have multiple owners. A business client may have subsidiaries, trusts, related entities, and multiple attribution rules.

The result: teams need to define how asset values move through the relationship model before they decide where to display the final AUM number.

Legacy vs. Standard/Core FSC AUM approach

How Should Teams Define AUM Before Configuring Rollups?

Teams should define AUM before configuring rollups by creating a short rulebook that explains what counts, what does not count, and how ownership should be attributed. This is the most important step because the technology can sum values, but it cannot decide the business meaning of AUM for you.

A practical AUM rulebook should answer these questions:

1. Which asset types count as AUM? Managed accounts, advisory accounts, brokerage accounts, annuities, cash, held-away assets, lending exposure, and insurance values may need different treatment.
2. Which statuses count? Most teams should exclude closed, inactive, test, historical, and duplicate accounts.
3. Which value field should be summed? Examples include current value, market value, balance, or a custom normalized AUM field.
4. How should multi-owner accounts be attributed? The organization must choose full attribution to a primary owner, proportional attribution by ownership percentage, or another documented rule.
5. Where should the result live? Household-level AUM may belong on Party Relationship Group, while entity-level AUM may belong on Business Account.
6. Who owns the definition? Business operations, compliance, finance, and advisory leadership should agree on the AUM definition before dashboards and advisor views depend on it.

Vantage Point often recommends separating raw rollup fields from display and segmentation fields. For example, Total_AUM__c can store the raw currency total, while formula fields or UI components can display tiers, labels, badges, and advisor-facing summaries.

How Do Record Rollup Definitions and Data Processing Engine Help?

Record Rollup Definitions and Data Processing Engine help by allowing admins to aggregate values across more complex relationship paths than classic rollup summary fields support. In Financial Services Cloud, that is especially important because the relationship from a household or business to financial assets can involve multiple objects.

A simplified household AUM path may look like this:

1. Party Relationship Group represents the household.
2. Group membership connects the household to people or accounts.
3. The person or account is connected to Financial Account Party.
4. Financial Account Party connects to Financial Account.
5. The rollup sums the qualifying Financial Account value back to the household group.

The exact join path depends on the org’s data model. That is why teams should not copy a generic rollup definition without validating their actual FSC configuration, record types, relationship objects, and ownership model.

Salesforce’s official documentation on Financial Services Cloud data models, Record Rollup Definitions, Record Rollup considerations, and group relationships in Financial Services Cloud is a useful starting point.

How Do You Configure Household AUM in the New FSC Data Model?

To configure household AUM in the new FSC data model, create a target AUM field on the household group, define the Financial Account value to sum, configure a Record Rollup Definition, and validate the join path and filters with test records.

Step 1: Create the target field

Create a custom currency field on the household target object, commonly Party Relationship Group.

Example:

Step 2: Identify the source value

Decide which source field represents AUM on the asset side. This could be a standard or custom field depending on the implementation.

Common examples include:

• Current value.
• Market value.
• Balance.
• Normalized AUM value.
• Adjusted AUM value.

If different product systems feed Salesforce with inconsistent values, create a normalized field first. This is where data migration and integration design becomes important, especially when asset values originate outside Salesforce.

Step 3: Configure the Record Rollup Definition

Configure a Record Rollup Definition with the household group as the target and Financial Account as the source.

Step 4: Define the join path

The join path is the part that most often causes confusion. The rollup must be able to traverse from the household group to the Financial Accounts that should count toward AUM.

A common conceptual path is:

Party Relationship Group → Group Member / Membership → Account or Contact → Financial Account Party → Financial Account

Your actual path may vary. Some orgs use household Accounts, some use Party Relationship Groups, and some use hybrid patterns because of legacy data or phased migration work. Validate the path against real records before relying on the result.

Step 5: Add filters to prevent bad totals

Filters should reflect the AUM rulebook.

Examples:

• Include only active financial accounts.
• Include only managed or advisory account types.
• Exclude held-away assets if they should not count as managed AUM.
• Exclude closed, inactive, test, or migrated placeholder records.
• Include only primary household relationships if the same person belongs to multiple groups.
• Include only records with a valid current value.

Step 6: Sync, activate, and test

After configuration, sync and activate the rollup. Then test it with a small set of known households before extending trust to dashboards or executive reporting.

A strong test set should include:

• A simple one-person household.
• A joint household with shared accounts.
• A household with held-away assets.
• A household with closed or inactive accounts.
• A household where the same person appears in multiple relationship groups.
• A household with multiple asset types.

How Should Business Account AUM Be Configured?

Business Account AUM should be configured either directly on the Business Account or on a business-type Party Relationship Group, depending on how the organization models entity relationships. The right answer depends on whether the business needs entity-specific AUM, consolidated relationship AUM, or both.

Option A: Roll up directly to Business Account

This option works when the business entity itself should show AUM directly on its Account record.

This pattern is useful for relationship managers who need an entity-level view on the Account record.

Option B: Roll up to a business relationship group

This option works when the business relationship includes multiple entities, subsidiaries, trusts, or related client structures. In that case, a Party Relationship Group can represent the broader relationship, while individual Business Accounts retain their own values.

For many financial services organizations, the best answer is not either/or. It is a layered design: direct AUM on Business Account for entity-level visibility and group-level AUM for consolidated relationship management.

How Should Multi-Owner Financial Accounts Be Handled?

Multi-owner financial accounts should be handled with explicit attribution rules on or around Financial Account Party. Without clear attribution rules, a shared account can be counted multiple times across households, businesses, or advisors.

There are two common approaches.

Approach 1: Proportional attribution

Use ownership percentage to calculate adjusted AUM. For example, if a Financial Account has a market value of $1,000,000 and Household A owns 60%, Household A receives $600,000 of attributed AUM.

This approach is more precise, but it requires reliable ownership percentage data and a field that the rollup can sum.

Approach 2: Primary attribution

Attribute 100% of the account value to a primary owner, primary household, or primary relationship group. This is simpler, but it must be clearly documented because it can distort relationship-level or household-level reporting if users assume proportional ownership.

Should Teams Use Formula Fields, Flow, FlexCards, or Analytics?

Teams should use Record Rollup Definitions for the core aggregation, formulas for labels and segmentation, Flow only when rollup logic cannot be handled declaratively through the rollup framework, and FlexCards or analytics for advisor-facing presentation. Each tool has a different job.

A good rule: calculate once, display many ways. Keep the core AUM calculation governed and reusable. Then expose it in the user experience where advisors and managers need it.

What Should Admins Validate Before Deploying AUM Rollups?

Admins should validate data quality, relationship paths, rollup filters, security, page layouts, and reporting logic before deploying AUM rollups. AUM becomes a trusted business number quickly, so small configuration errors can create large downstream confusion.

Use this checklist before launch.

AUM configuration checklist

• Confirm the official AUM definition with business stakeholders.
• Identify the exact source field used for value.
• Decide whether held-away assets count.
• Decide how closed, inactive, or migrated accounts are excluded.
• Confirm whether AUM rolls to Party Relationship Group, Business Account, or both.
• Validate Financial Account Party roles and ownership percentages.
• Test households with shared accounts.
• Test business entities with related groups or subsidiaries.
• Confirm field-level security and page layout visibility.
• Confirm the number matches source-of-truth systems for sample records.
• Document the rollup logic for admins, analysts, and compliance stakeholders.
• Train advisors on what the AUM number does and does not mean.

What Can Go Wrong With FSC AUM Rollups?

FSC AUM rollups can go wrong when teams configure the math before resolving the data model. Most issues are not caused by Salesforce’s ability to calculate; they are caused by unclear definitions, inconsistent relationships, or incomplete integration logic.

What Businesses Should Do Next

Businesses should treat FSC AUM configuration as a small architecture project, not just an admin field request. The work touches data definitions, relationship modeling, advisor workflows, compliance expectations, reporting, and integration quality.

A practical next step is to run a focused design session with four outputs:

1. AUM definition: What counts, what does not, and why.
2. Attribution model: How shared accounts, businesses, trusts, and relationship groups are handled.
3. Technical pattern: Target objects, source fields, join paths, filters, and rollup definitions.
4. User experience: Where advisors, managers, and operations teams see AUM and how they should act on it.

If your team is evaluating how this applies to Salesforce, Financial Services Cloud, integrations, or CRM governance, Vantage Point can help assess the right next step and build a practical implementation plan.

How Vantage Point Helps

Vantage Point helps organizations evaluate, implement, and optimize Salesforce and HubSpot based on their operating model, data needs, adoption goals, and growth strategy. For Salesforce Financial Services Cloud teams, that often includes translating business rules into scalable CRM architecture.

For FSC AUM rollups, Vantage Point can help with:

• Salesforce implementation and advisory for Financial Services Cloud architecture, data model decisions, and rollout planning.
• System integration and data migration when account values, balances, or asset data originate in portfolio, custodian, core, or external systems.
• Compliance and security solutions for field visibility, data governance, and access controls around sensitive client value data.
• Managed services and ongoing support for admin backlog, FSC optimization, reporting improvements, and post-launch support.
• Advisory and change management so advisors understand how to use AUM consistently in daily workflows.

The goal is not just to display a number. The goal is to create a trusted CRM signal that supports better client service, cleaner reporting, and more confident relationship management.

FAQ

Does Salesforce Financial Services Cloud Standard/Core still support Total AUM?

Yes, Salesforce Financial Services Cloud Standard/Core can still support Total AUM, but teams usually need to configure the calculation instead of relying on a legacy preconfigured Account field. The recommended pattern is to use Record Rollup Definitions with Data Processing Engine and a clearly defined relationship path.

Where should household AUM be stored in the new FSC data model?

Household AUM is often best stored on Party Relationship Group when that object represents the household relationship. Some orgs may still use Account-based or hybrid household patterns, so the right target depends on the actual implementation. The key is to store the value where users expect to manage the household relationship.

Can AUM be rolled up to Business Accounts?

Yes, AUM can be rolled up to Business Accounts when the business entity itself needs an entity-level AUM value. For more complex business structures, a business-type Party Relationship Group may be better for consolidated AUM across related entities.

Should Flow be used to calculate AUM?

Flow can support exception logic or related automation, but it should not be the first choice for scalable multi-hop AUM aggregation when Record Rollup Definitions and Data Processing Engine can handle the rollup. Use the rollup framework for the core calculation and Flow for surrounding business processes.

How do you avoid double-counting shared financial accounts?

You avoid double-counting shared financial accounts by defining attribution rules before building the rollup. Common options include proportional attribution using ownership percentage, primary-owner attribution, or carefully filtered full attribution depending on the reporting need.

What is the biggest mistake teams make with FSC AUM rollups?

The biggest mistake is treating AUM as a simple field replacement from the legacy data model. In the Standard/Core model, teams should validate the relationship path, define the AUM policy, and test shared ownership scenarios before using the number in advisor views or leadership dashboards.

Can Vantage Point help configure FSC AUM rollups?

Yes, Vantage Point can help design, configure, test, and document FSC AUM rollups. That work often includes Salesforce Financial Services Cloud architecture, data integration review, Record Rollup Definition configuration, reporting, and change management for advisor adoption.

Should held-away assets be included in AUM?

Held-away assets should be included only if the organization’s AUM definition says they count. Many firms separate managed AUM, held-away assets, lending exposure, and total relationship value so advisors get useful context without blurring regulated or operational definitions.

Source Notes

This post was based on an anonymized Financial Services Cloud admin question about configuring Total Assets Under Management in the new Salesforce Financial Services Cloud Standard/Core data model, plus Salesforce documentation on FSC data models, Record Rollup Definitions, Record Rollup considerations, and group relationship modeling.

External resources referenced:

• Salesforce Help: Financial Services Cloud Data Models
• Salesforce Help: Record Rollup Definitions
• Salesforce Help: Record Rollup Definitions Considerations
• Salesforce Help: Group Relationships in Financial Services Cloud