Salesforce ships two ways to summarise child records into a parent: roll-up summary fields (on master-detail relationships) and custom Apex (for anything else). Neither one fits the Financial Services Cloud data model cleanly.
The FSC schema is full of lookups, not master-details. A Person Account looks up to a Household. A Financial Account looks up to its Primary Owner. An Asset looks up to a Financial Account. None of these are master-detail because the parent-child relationship can change over time (clients move households, accounts get reassigned, holdings transfer between accounts). Master-detail's tight lifecycle binding would break the model.
Rollup By Lookup (RBL) is the FSC engine that fills the gap. It is a declarative rollup configuration that summarises child records up a lookup relationship without the master-detail constraint. Most of an FSC implementation's reporting accuracy depends on RBL being configured well.
What RBL actually does
RBL is a set of metadata records that define rollup rules:
- Filter Criteria. Which child records contribute to the rollup. For a household's "Total Deposits" rollup, the filter might be Financial Account Status = Active AND Financial Account Type = Banking.
- Group By Field. The lookup field on the child object that points to the parent. For Financial Account rolling up to Household, the group-by is the Primary Owner field on Financial Account.
- Rollup Operation. Sum, count, max, min, average. RBL supports all five.
- Rollup Field. The child field to aggregate. Balance, count of records, max balance, average return.
- Destination Field. The parent field that receives the rollup. Household.Total Deposits, Household.Account Count, Household.Largest Position.
The RBL engine evaluates the rules whenever a child record is inserted, updated, or deleted, and propagates the changes to the destination field on the parent. The propagation runs asynchronously in most production orgs, with a typical lag of a few seconds.
The standard FSC rollups
FSC ships a starter set of RBL rules out of the box, covering the most common wealth-management summaries:
- Household.Total Assets. Sum of Balance on active investment and banking Financial Accounts belonging to household members.
- Household.Total Liabilities. Sum of Balance on active mortgage and credit-card Financial Accounts.
- Household.Net Worth. Difference of the two above, computed by a derived rollup.
- Account.Total Financial Accounts. Count of Financial Accounts where Primary Owner equals the Account.
- Financial Account.Total Holdings Value. Sum of Asset.Current Value where the Asset is on the Financial Account.
Most implementations start here and extend. Custom rollups follow the same pattern: define filter, group-by, operation, source field, destination field.
Configuration surface
RBL configuration lives in two places:
Custom Metadata Type records. The actual rollup definitions are stored as Custom Metadata Type records that the FSC managed package reads. Defining a new rollup means creating a new metadata record with the appropriate fields populated.
Permission Set assignments. Users who execute child-record changes need permission for RBL evaluation. The FSC Foundations and FSC Extension permission sets carry the required permissions; admin-level configuration usually does not need additional grants.
The configuration UI shows up in Setup under the FSC App Settings node, but production teams typically build the rules through deployment metadata rather than clicking through Setup. The metadata-as-code pattern keeps the rollup definitions in source control.
The limit problem
RBL's biggest production constraint is governor limits. Each child-record change triggers an RBL evaluation, which runs as Salesforce-internal Apex. The Apex executes inside the same transaction that produced the child-record change. Large batch updates that touch thousands of child records produce thousands of RBL evaluations, all in one transaction.
Two patterns mitigate the limit risk:
Bulk-update batching. Integrations that load Financial Account updates should batch in chunks of 200 or fewer records. The 200 limit aligns with Salesforce's standard bulk-DML limit and keeps RBL evaluation within the per-transaction CPU budget.
Async RBL recompute. For very large initial loads or for rollup-rule changes that need to back-fill historical data, FSC ships a batch recompute utility that runs the rollup evaluation asynchronously. The utility is the right pattern for any single-event update over 10K records.
Implementations that miss these patterns hit production issues that are hard to diagnose. The symptom is "rollups disagree with source data by a few percent". The cause is silent partial RBL failure during a high-volume update.
What RBL does not do
RBL handles sums, counts, and basic aggregations on lookup relationships. It does not handle:
Hierarchical rollups across more than two levels. A child rolls up to a parent rolls up to a grandparent is two RBL rules in sequence. 3-level rollups work but get fragile fast. Most production orgs limit themselves to two levels of RBL chaining.
Cross-object joins inside the rollup. RBL evaluates one child object at a time. A rollup that needs to combine Financial Account data with Asset data into a single household-level number needs custom Apex or a custom report type.
Time-series rollups. RBL gives the current sum. The sum-as-of-last-month and the trend over time are not RBL's job; they belong in reporting tools or in a historical-data structure built outside of RBL.
Currency conversion inside the rollup. RBL sums the source-field values directly. Multi-currency rollups need either a pre-conversion step (rolling up in source currency, converting at the destination) or a derived field that pre-converts the source value before the rollup runs.
Each limitation has a workaround; none of them mean RBL is the wrong tool. They mean RBL is one part of the data-shape toolkit, not the whole toolkit.
Diagnosing rollup drift
Production orgs occasionally see drift between RBL outputs and source-data sums. The diagnostic order:
Step 1: Recompute manually. Write a SOQL query that performs the same sum the RBL rule should produce. Compare to the destination field value. If they disagree, the RBL output is stale.
Step 2: Check filter criteria. The RBL rule and the manual recompute should use identical filter criteria. Mismatched filters (the manual query missing a status filter the RBL rule has) explain most apparent drift cases.
Step 3: Check for async backlog. Salesforce's async-job queue can back up under heavy load. The FSC App Manager surface shows pending RBL jobs. A growing queue means the org is producing changes faster than the queue can drain.
Step 4: Manual RBL recompute. The batch recompute utility forces a full RBL evaluation across the affected parent records. The recompute is the universal fix for any genuine drift.
Diagnosing drift quickly matters because the rollups drive advisor-facing dashboards. A wealth advisor whose dashboard shows an incorrect Household Net Worth loses trust in the platform faster than from any other defect.
The implementation-time pattern
For an FSC implementation reaching the RBL configuration stage, the workflow that has held up:
- List every rollup the business asks for. Group them by parent object and by operation type.
- Sketch each rollup as one RBL rule. Filter, group-by, operation, source, destination.
- Build the destination fields on the parent objects first. Make sure the data types align (Currency rollups need Currency destinations).
- Build the RBL rules through metadata, one at a time, with sandbox data exercising each before promoting.
- Build the manual-recompute SOQL queries as part of the rollup-validation script. Run the queries on Day One and weekly thereafter for a month.
- Wire the batch-recompute utility into the deployment scripts for rule changes.
The discipline is unglamorous. The payoff is rollup data that advisors trust at production scale.
Configuring RBL for an FSC implementation? Sapota's Salesforce team, certified on Financial Services Cloud Accredited Professional (AP-208), runs RBL design, deployment, and drift-diagnostic tooling on every FSC engagement. Get in touch ->
See our Salesforce service page for our team and credentials.
