Relationships in Financial Services Cloud: Clients and Households

Relationships. One would think that building a great relationship structure in Salesforce’s Financial Services Cloud would be less complex than maintaining relationships in person, but often it is not. Relationships in FSC require a bit of trial and error, defined business processes, and some patience.

Having completed a dozen FSC implementations as of this writing, I can speak to the unique challenges that the FSC data model presents and ideas and best practices for how to overcome these challenges. In the first of a mini-series, we’re going to explore Households and People.

If you’re unfamiliar with FSC or want a quick refresh on FSC’s data model and features, check out my FSC primer post titled Getting Started with Financial Services Cloud.

Person Account vs Individual: Choosing the Right Account Model for your Clients

Right out of the gate, there is a choice. Specifically, how to represent client records. FSC provides two models to choose from, and both have implications.

The Person Account model is the preferred model for FSC and is enabled and setup as the default data model for all new FSC orgs.

For those unfamiliar, a Person Account “…store[s] information about individual people by combining certain account and contact fields into a single record.” (Source) Person Account records have been around for quite a long time but have typically been the source of frustration for many System Administrators because of some of their limitations. However, Salesforce has done a great job of enhancing and supporting Person Accounts in recent years and with FSC, they seem to finally found a proper home.

Person Accounts are great because they are single records representing both an Account and a Contact which means it has great flexibility in the FSC data model – being able to reference it in both Account and Contact lookup fields.

One major downside of the Person Account model is that they have been generally discarded by the AppExchange ecosystem so finding applications that are compatible with Person Accounts can be difficult. This is where the Individual model makes it’s appearance.

Ugh.

Financial Services Cloud was (and is) released as a Lightning-only product which means that the full suite of FSC features works only in Lightning Experience. At the time that FSC was released, Person Accounts were not supported in Lightning Experience. So, Salesforce created a pseudo Person Account called the Individual.

Similar to Person Accounts, Individuals leverage both an Account and Contact record. But, unlike Person Accounts, they operate as two distinct records. The FSC team has worked hard make Individuals behave like Person Accounts through quite a bit of code and validation rules, but it’s not the same and they are a royal pain. Here are some of the drawbacks to the Individual model:

• FSC comes with a LEX component that redirects users from an Individual Contact to an Individual Account. It increases the navigation and load times of the records and can cause some confusion for users. The component can be removed, but doing so provides users with two distinct records (Account and Contact) that the user can navigate compounding the confusion.
• Creating an Individual Account automatically creates an Individual Contact and relates them together (and vise versa). This means that you cannot use just the Individual Contact or just the Individual Account. They work together and the setting cannot be turned off.
• Building formulas on data from the Individual requires the use of a specific FSC lookup field called “Primary Contact” which links the Individual Account and Individual Contact together.
• Showing related records from the Individual Contact also requires the use of the Primary Contact lookup field (to show Campaign History from the Contact for example).
• FSC has a custom LEX component to display Account and Contact fields on a single record, but you cannot mix account and contact fields together – the fields display in two distinct sections on the layout. This means that information that would normally be grouped together may live in two distinct areas on the Individual records, requiring the user to scroll.
• Clicking Edit on the Individual Account allows users to edit only Account fields – not Contact fields. You’ll have to use inline editing to edit Contact data (assuming the Redirect LEX component remains on the Individual Contact layout).
• Individual Accounts are not supported in Salesforce’s duplicate management application. Should a duplicate be identified, you’ll need to use data loader to update the parent record and migrate related records from the duplicate candidates to the master and finally delete the duplicates. It’s a process.
• List views on Accounts doesn’t pull in Contact related fields unless you create formula fields on the Account, creating extra configuration overhead.
• …and much more.

The Individual model is riddled with hurdles that you’ll need to overcome if you choose (or are forced into) this model.

Why this is even a decision you’ll need to make – especially if the Person Account model is the default model?

The answer comes down to third-party apps. There are still a number of critical applications that do not support the Person Account model. Specifically, Portfolio Management Applications like Tamarac do not currently support Person Accounts at the time of this writing. (For the record Orion does “support” Person Accounts but it’s because they don’t really use them in their integration).

Since Accounts are core to the overall Salesforce data model, this decision has downstream implications so choosing the right account model is critical. However, if you do need to use the Individual Model, Salesforce has an upgrade path to convert your data to Person Accounts. If you’re forced into the Individual Model, my suggestion would be to upgrade to Person Accounts as soon as you’re able.

Traditional Business Account and Contact Model

At this point, you may be wondering why use the Person Account or Individual Account models at all. Why not just use the standard Account and Contact model? After all, there are many Financial Services clients who don’t use FSC and this is the model that they use!

The difference is in how FSC is setup. Rollups of Financial Account data and other configuration specific to FSC works with the prescribed models. Meaning, FSC specific functionality would be lost if you use a non-FSC model to represent the data. This specifically includes data aggregation at the Household.

However, this data model is used to represent non-client Business Accounts and Business Contact records (think CPAs and Attorneys). But even in this model there are additional considerations in FSC – but we’ll cover that in a future post!

Households and Account-Contact Relationships

Salesforce’s standard data model allows for one-to-many and many-to-many relationships between Contacts and Accounts, but FSC adds the ability to visualize this in a way makes those relationships easy to understand – especially for Households.

Householding is meant to group Person Accounts/Individuals together under a single umbrella Account called a Household. FSC provides supporting functionality such as aggregated rollups of financial account balances, activities, and supporting objects that makeup a client’s net worth.

The relationship between a Person Account/Individual and the Household Account is made through the Account-Contact Relationship object (ACR) which serves as a junction object and includes additional settings such as a defined Role, Start Date, End Date, and how rollups to the Household should behave.

Account-Contact Relationships allow for a single Contact (or Person Account) to be linked to any number of other Accounts. You can begin to see the complexity this presents as you think about your Client’s relationships.

In addition to Account-Contact relationships, there are also Account-Account and Contact-Contact Relationships in FSC which allow for many to many relationships in these other variations.

It is still true that a Contact must have a “direct” relationship to an Account (standard data model applies). The Person Account and Individuals accommodates this through their own unique builds, being both an Account and Contact. Standard Contacts do this by requiring an Account relationship. All other relationships through the ACR, AAR and CCR objects are secondary relationships.

Households may be somewhat of a foreign concept to wealth firms migrating from a CRM like Redtail or Junxure because the Households (or Families as its called in those systems) serve as a simple relationship tool. No data is aggregated to the Household in these other CRMs and users don’t interact with the Household in Redtail or Junxure like they do in Salesforce. Redtail and Junxure puts the client record front and center whereas Salesforce wants the Household front and center.

Mix in the concept of the Household being an entirely new record in Salesforce as well as the relationships that Households and Person Account/Individuals can have through the Account-Contact, Account-Account, and Contact-Contact Relationships, and the web of relationships gets complex fast.

Creating Households and Person Accounts/Individuals

One last relationship complexity to be aware of for this post is the creation of the Household and Person Account/Individuals. One complaint is that Salesforce does not automatically create a Household when creating a Person/Account Individual record. For many wealth management firms, all of their clients belong to a Household and often many portfolio management tools (such as Orion and Tamarac) also require a Household.

Here is a typical workflow that an Advisor may work through when creating a new Household of five (two clients and three dependents):

1. Create the Household record.
2. Create the Primary Person Account/Individual Record.
3. Indicate the Rollup and Relationship preferences on the Account-Contact Relationship record for the Primary.
4. Create the Spouse Person Account/Individual Record.
5. Indicate the Rollup and Relationship preferences on the Account-Contact Relationship record for the Secondary.
6. Create the 1st dependent Person Account/Individual Record.
7. Indicate the Rollup and Relationship preferences on the Account-Contact Relationship record for the 1st dependent.
8. Create the 2nd dependent Person Account/Individual Record.
9. Indicate the Rollup and Relationship preferences on the Account-Contact Relationship record for the 2nd dependent.
10. Create the 3rd dependent Person Account/Individual Record.
11. Indicate the Rollup and Relationship preferences on the Account-Contact Relationship record for the 3rd dependent.
12. Save the Account-Contact Relationship updates.

Depending on whether you capture dependent records in your org these steps may grow or shrink, but it does indicate the inefficiency that FSC presents when creating a new Household.

At ShellBlack, we have created custom code that cuts down this process significantly, but you could also look at adding a custom Flow or other solution. Either way, the Household and Client relationship itself can be complex to setup and that’s before you start building additional relationships between non-client Contacts and Accounts.

In the next post, we’ll learn how Business Accounts & Business Contacts work in FSC, why you would use them, and options for how to structure these records in your FSC org.