Salesforce Financial Services Cloud ships four native rollup engines that split along one line. Record Rollups (managed package) and Record Rollup Definitions (standard) aggregate records to a client or household. Rollup By Lookup and RBL on Data Processing Engine calculate financial totals such as AUM and account balances. On the standard FSC data model, use Record Rollup Definitions for record aggregation and Financial Summary Rollup for numeric totals. On the managed package at scale, move RBL onto Data Processing Engine.
Every Financial Services Cloud implementation eventually hits the same request: show the advisor one number for the household. Total assets under management. Total deposits. Total insured value.
It sounds like a reporting problem. It is a data model decision, and Salesforce gives you four native ways to make it. They are not interchangeable, they arrived at different points in the product's life, and two depend on the managed package. Pick the wrong one and you inherit rollup logic nobody can safely change three releases later.
One naming note: Salesforce Help now calls the product Agentforce Financial Services, formerly Financial Services Cloud. The features and object names below are unchanged.
Because FSC has two data models and two kinds of rollup.
FSC launched as a managed package. Since 2019 Salesforce has delivered features on the standard platform instead, and Salesforce Help now states that the default and recommended implementation approach is directly within the core platform. Foundational capabilities including Groups and Households and Rollups reached the standard platform in the Winter '23 and Summer '24 releases.
That produced a matched pair for each rollup type. Salesforce documents the mapping in its rollups comparison: Record Rollups (managed package) corresponds to Record Rollup Definitions (standard), and Rollup By Lookup Rules corresponds to Financial Summary Rollup. That grid is most of the decision.
Record Rollups aggregate information from related records at a client or group level. This is a managed package feature: client-level aggregation happens by default with no setup, and group-level rollups must be enabled.
When group rollups are on, qualifying records are stamped with the primary group in the Household__c lookup field, which drives household components and related lists. Salesforce warns against changing that field, because edits cause inconsistent group-level rollups. Supported objects include Financial Account, Financial Goals, Assets and Liabilities, Referrals, Events, Tasks, Opportunities, Case, Claim, Insurance Policy, and their participant objects. Opportunities, policies, claims, and referrals require extra picklist values on the Rollup__c field of Account Contact Relationship.
Processing runs in real time through triggers, or in batch through the GroupAssignmentBatchable and HouseholdAssignmentBatchable jobs — only one of the two per org.
The structural limit: a record can be associated with only a single household. Fine for a simple family, painful for blended families, trusts, and multi-generational relationships.
Rollup By Lookup (RBL) rules produce the numbers. When a financial account record or a primary group membership changes, RBL updates the corresponding client- and group-level summaries. RBL rules are available only for Assets and Liabilities, Claims, Financial Accounts, Financial Account Roles, Insurance Policies, and Revenues. The package ships roughly 52 RBL configurations covering AUM, banking totals, investments, outstanding credit, insurance premium, and claim counts.
The line every architect should read before touching RBL sits in that same article: Salesforce states it does not recommend or provide support for creating or customizing FSC RBL rules. Cloning packaged rules is common practice, but you are on your own for support. Treat any custom RBL rule as technical debt with a known expiry date.
RBL on Data Processing Engine is the same rule set, converted into DPE definitions that run on the CRM Analytics processing engine. Salesforce positions it as significantly faster, with more flexibility: multiple data sources, joins and appends, and formulas. Two things to know before enabling it.
First, it is close to a one-way door. Salesforce documents that after you enable the RBL Using Data Processing Engine setting, you can no longer create, update, or delete RBL rules in the old framework.
Second, DPE has real ceilings. Per Salesforce's documented limits, an org can have up to 50 active definitions; a definition can contain up to 500 nodes and 50 data source nodes; and on the CRM Analytics runtime, Data Pipelines caps processing at 10 million rows and 30 hours per month, one concurrent recipe, and 1 GB of writeback per rolling 24 hours. DPE is also unavailable in Government Cloud and Government Cloud Plus.
Definitions execute via flow, REST API, or Apex trigger, making this a scheduled-batch pattern rather than a real-time one.
Yes — for record aggregation. Record Rollup Definitions are the declarative, standard-object framework, available without the managed package in Professional, Enterprise, and Unlimited editions where FSC is enabled.
You build them in Setup by naming a rollup source object, a target object, join conditions, and filter conditions. Salesforce syncs the definition to a Data Processing Engine definition, and a schedule-triggered flow executes it. Results surface through the ShowRecordRollupResults FlexCard on the target record page, and on-demand refresh can be enabled per definition.
Two improvements over the managed-package version are documented directly: you can roll the same record up to multiple households, and you can apply filter conditions.
The considerations list is where projects get surprised. You cannot select Account as a rollup source object. Financial Goal is effectively unusable as a source because its required intermediary, Financial Goal Party, is not supported. Join fields must be Lookup or Master-Detail, and compound fields cannot be join or filter fields. And critically, a single DPE definition is linked to all active record rollup definitions, so triggering the flow runs all of them — and they count against your org's DPE limits even though the underlying definition is not visible to you.
Here is the correction that saves projects: Record Rollup Definitions do not replace RBL. They replace Record Rollups.
The standard-object replacement for RBL's financial totals is Financial Summary Rollup: eight predefined Data Processing Engine definitions that write aggregated values into the Account Financial Summary object, with fields such as Total Investment Value and Total Gross Written Premium Amount. Salesforce publishes a rule-by-rule mapping from the managed-package RBL rules to those eight standard definitions, split across client- and household-level summaries.
Teams that assume Record Rollup Definitions will produce household AUM tend to discover this several sprints in. If the requirement is a currency total, start with Financial Summary Rollup.
| Engine | Produces | Data model | Timing | Best for | Main constraint |
|---|---|---|---|---|---|
| Record Rollups | Records stamped to a household | Managed package | Trigger or batch job | Legacy managed-package orgs needing household related lists | One household per record; no filter conditions |
| Rollup By Lookup (RBL) | Currency and count totals | Managed package | Updates on record edit | Existing packaged summaries in lower-volume orgs | Not recommended or supported for custom rules |
| RBL on Data Processing Engine | Same totals, converted to DPE | Managed package | Scheduled batch | High-volume managed-package orgs | Enabling it locks the legacy framework; DPE limits apply |
| Record Rollup Definitions | Aggregated record sets | Standard objects | Scheduled flow, plus on-demand refresh | New builds needing record rollups with filters | No Account source; shared DPE definition |
| Financial Summary Rollup | Currency and count totals | Standard objects | Scheduled flow | New builds needing AUM, balance, and policy totals | Eight predefined definitions to adopt and adapt |
Four rules of thumb:
Mixing engines for the same figure. Two engines writing to overlapping fields produce numbers that disagree depending on which ran last. Assign one owner per metric and document it.
Assuming real time. Record Rollup Definitions, Financial Summary Rollup, and RBL on DPE all run on scheduled flows. Advisors who expect a balance to change the moment a record saves need to be told otherwise, or given on-demand refresh.
Ignoring DPE ceilings. Record Rollup Definitions consume a Data Processing Engine definition behind the scenes, so orgs can approach platform limits without realizing it. Track DPE usage in release planning.
Doing rollups before household modeling. Blended families, trusts, and business relationships determine whether a one-household-per-record engine is viable at all. Fix the group model first.
Skipping the migration mapping. When moving off the managed package, use Salesforce's published RBL-to-standard mapping so the new totals mean what the old ones meant. Run both in parallel and reconcile at record level before retiring anything.
Salesforce also publishes DPE performance best practices: disable updates to the Primary Contact field on Account when using person accounts, bypass triggers on target objects for the users running rollups, and group definitions by source and writeback combination.
Rollup configuration is straightforward. Rollup architecture is not. Bring in help when the household model itself is in question, when you are migrating off the managed package and need parallel-run reconciliation, when DPE runtimes threaten your batch window, or when compliance requires documented lineage for a reported figure.
Choosing a rollup engine is a decision you live with for years. Vantage Point helps banks, wealth managers, and insurers design household structures, select the right engine, migrate legacy RBL logic onto the standard model, and prove the numbers before advisors depend on them. Every engagement is staffed with senior consultants only — no junior handoffs on your data model.
Talk to Vantage Point about your FSC rollup architecture or get started here. Related services: Salesforce implementation and advisory, system integration and data migration, and managed services and ongoing support. Also read our FSC Core vs. managed package migration guide.
They can technically coexist, but running both against the same metric creates conflicting values. Salesforce documents them as equivalent alternatives, so treat the choice as exclusive per metric and object.
They aggregate records, not currency totals. For household or client AUM on the standard data model, start with Financial Summary Rollup's predefined DPE definitions and adapt them to your policy. See our FSC AUM rollups guide for configuration detail.
Salesforce has not published a retirement date. It does state that it does not recommend or support creating or customizing FSC RBL rules, and that the standard platform is the recommended approach. Plan accordingly rather than waiting for an end-of-life notice.
Salesforce documents that once the setting is enabled, you can no longer create, update, or delete rules in the legacy RBL framework. Validate the conversion in a sandbox with production-scale data first.
Users need the Record Aggregation Access permission, delivered through FSC permission sets such as FSC Foundations. Admins also need Data Pipelines Base User to create, activate, and sync definitions, plus OmniStudio permissions for the results component.
Managed-package RBL updates when the underlying record or membership changes. Everything DPE-backed runs on a schedule you control through a schedule-triggered flow. Record Rollup Definitions also support on-demand refresh when enabled at both org and definition level.
No. Salesforce documents that Data Processing Engine is unavailable in Government Cloud and Government Cloud Plus, which rules out the DPE-backed engines for those customers.
Vantage Point is a senior-led Salesforce, HubSpot, integration, and AI consulting firm serving banks, wealth managers, insurers, and fintech companies. We turn CRM architecture decisions into governed, maintainable systems.