Summarize Financial Data in Salesforce FSC

Photo by Yan Krukau from Pexels

When a financial firm implements the Salesforce Financial Services Cloud (FSC), a key benefit is the ability for financial advisers/consultants and customer service reps to assess a client’s value to the firm. There are lots of ways to measure that, but the most common is summaries: net worth, asset allocation, wallet share, and so forth. Traditional Salesforce calls for reports and dashboards to produce these summaries, but FSC offers a better approach.

As architects and developers, we can take advantage of FSC’s aggregation methodologies (commonly called “rollups”). By aggregating financial data behind the scenes and storing it in fields on the client and household records, we gain several benefits:

• Summarize only when a change occurs (and we control what changes drive which summaries).
• Pages load faster (since there’s no calculation being done on the fly).
• Simplified reporting, where only one object is being referenced.
• Leverage FlexCards, quick actions, and native components to provide a quick summary of the client’s or household’s financial landscape.

There are two very different models for performing these rollups, with two very different tools used to define and execute them:

1. Real time, leveraging user-driven record changes

2. Bulk loads, incorporating large daily and ad hoc data loads

Both approaches can produce the desired result, but performance and user experience are improved by choosing the right tool at the right time. This post will provide some guidance about when to use one over the other, and some best practice recommendations for each.

What do we mean by “rollup”?

Rollups are simply aggregations of certain child records for a client or household. Those aggregated values are then stored in fields on the client or household.

For financial accounts and assets & liabilities

For the sake of simplicity, we’ll concentrate on financial accounts. The same basic rules apply for assets & liabilities.

For context, remember three rules:

1. A client may belong to multiple households, but only one household at a time can be considered that client’s primary household.
2. A financial account (FA) must have exactly one primary owner. The primary owner is simultaneously recorded as a record in the financial account role object.
3. If a FA’s primary owner has a primary household, the FA is considered to belong to that household.

Note: The FA may have a joint owner as well, and that too is automatically recorded in the same junction object. Other FA roles are likewise recorded in the same object, but that recording is not automatic.

With that in mind, rollups generally follow this pattern when an FA is modified:

• Update the primary owner’s record with the aggregate value of all FAs for that primary owner.
• Update the household record (if a household is identified on the FA) with the aggregated value of all FAs that belong to that household.

Any FAs created for a householded client are automatically branded with that household.

Other entities

You might think of rollups as a strictly financial account exercise, but you can perform this aggregate action for other client attributes as well. A very common example is income.

The key distinction is FSC’s ability to manage rollups in real time. FAs and A&L are Apex trigger-driven and hardwired into the FSC architecture. Custom objects and other FSC package objects are not, so the ability to dynamically aggregate those values is limited. In those cases, you have two choices:

1. Use the Data Processing Engine (discussed below), or
2. Write your own triggers to perform similar actions.

What are we rolling up?

As mentioned above, we’re commonly rolling up the value of a FA (or an asset).

But which values?

For example, most companies want to break out investment assets from banking, and each of those from loans. There are other common distinctions:

• Primarily owned vs. jointly owned
• Active vs. dormant
• Registration type, held away, or other characteristics
• Age of FA

The key here is to identify these distinctions up front and create the appropriate fields on the account object. Here’s a common approach:

Real-time changes

When is this appropriate?

Only use this when responding to user interaction, such as modifying a client-household relationship or explicitly changing important values of a financial account via the user interface (UI).

Since this is trigger-based and relies on SOQL, it’s subject to all the performance issues those introduce. For smaller implementations this can work fine. However, if you’re working with a large load of data (e.g., a daily batch update from an institution’s back end), you’ll quickly hit limitations that require very complex work-arounds.

How does this work?

When a user makes a change to any of several objects, a FSC trigger fires. This applies primarily to these objects:

There are other objects that can fire FSC’s rollup triggers. We’re just concentrating here on the common use cases for wealth and banking.

The triggers take two actions:

First, determine what steps should be taken, primarily:

• Am I branding the financial account with the household?
• Am I rolling up the financial account values?

Second, execute the updates as indicated by the contents of the Rollup by Lookup (RBL) configuration.

RBL is a custom object introduced by FSC. It allows you to define the calculations to perform, and those calculations are executed by the FSC rollup triggers. RBL allows you to define several elements to drive those calculations, but mainly:

• The object where the change occurred (e.g., financial account)
• The field whose value change kicks this off (e.g., balance or status)
• Any filters (e.g., record type) to narrow the scope
• The type of update to perform (e.g., a COUNT of records, or a SUM of values)
• The related record to be updated (e.g., primary owner, which points to a person account record)
• The field on that record we’re updating

Best practice recommendations

• Identify up front as many fine-point calculations (i.e., “Banking vs. Brokerage” combined with SUM vs. COUNT) as you can and do one pass through your schema to create the fields to hold them.
• For simple math (e.g., combining “$” values across calculations), use formula fields on the client/household object rather than trying to build that into an RBL definition. For example, if we rollup “Checking” and “Savings” values into discrete fields, you could create a “Total cash” formula of Checking + Savings.
• Use the Wealth Management Settings custom setting to establish a hierarchy list to allow tight control over the users (e.g., integration vs. standard) whose changes will invoke RBL. For integration users, disable the rollup behavior (“Enable Rollup Summary”) and enable the Household assignment (“Enable Group Record Rollups”).
• Name your RBL definitions (as well as naming/labeling their target fields) using a consistent convention: Object — Value — Calculation (for example: “Financial Account — Banking — SUM”). This allows easier identification during maintenance.

Bulk-driven changes

When is this appropriate?

In the financial services world, it’s common to have a daily true-up of clients, their associated FAs, and the FA attributes (particularly balance and status). This is commonly executed via a daily batch loaded via MuleSoft or some other integration pattern.

A regional bank may have 100,000 clients and a quarter-million FAs; a larger national brokerage may have many millions of each. These data volumes are well beyond the capacity of SOQL (the mechanism underlying real-time RBL calculations) to effectively manage.

In this context, it’s much better to use a tool geared toward off-line calculation of large datasets. For FSC, this tool is the Data Processing Engine (DPE).

How does this work?

DPE is FSC’s front-end interface to leverage CRMA’s (formerly Tableau) data engine. Performing calculations with DPE essentially follows this process:

• Define the universe of data and rules (a.k.a. “recipe”) as a DPE definition
• Replicate the appropriate Salesforce data (using Data Pipelines invoked via Flow or Apex)
• Within DPE, apply filters, formulas, and aggregations to replicated data and calculate results
• Write the resulting aggregations to the selected Salesforce target object(s)

Configure and execute in Salesforce. Calculate in — and write back using — DPE.

Since this is a batch-driven process, it is not a good fit for real-time calculations where users expect to see immediate results.

However, it is a good fit when the source objects being calculated are not among those enabled by FSC’s trigger framework (e.g., employment or other custom objects).

Best practice recommendations

• Create your RBLs first and use them as a guide for the calculations you’ll need to build in DPE.
• Map out your calculations and recipe design carefully up front. When using the DPE UI, it’s a lot easier to build from a narrow blueprint than to use a build-refine-rebuild pattern.
• Do not rely on Salesforce’s recommendation to convert your RBLs into DPE definitions; create your definitions from scratch. Salesforce will create one DPE definition for every RBL you convert, which results in very inefficient — and potentially error-generating — aggregations (see the next point below).
• Combine your aggregations within DPE so you’re performing only a single write to each record. The DPE engine allows you create multiple write-backs as part of your definition, but it deals with each update individually. If you have multiple fields to update on the same record (e.g., “Savings $” and “Checking $”), and you use multiple write-backs to make those updates, it will almost certainly generate record-locking errors.

Aggregating once for each value, then assemble into a common set and reaggregate before writing back.

Conclusion

There is no “right tool” for aggregating your clients’ data; it’s very much about using the right tool for the circumstances. If you need real-time rollups, use the Rollup by Lookup configuration. If you are loading batches, use Data Processing Engine.

Doing this well takes time, and an experienced hand can help. Please reach out to us at Slalom if you need some help; we’re always happy to partner with you.

Slalom is a global consulting firm that helps people and organizations dream bigger, move faster, and build better tomorrows for all. Learn more and reach out today.