Relationships in Salesforce Financial Services Cloud

Relationships. One might think that building a good relationship with Salesforce’s Financial Services Cloud would be harder than maintaining a personal relationship, but that is often not the case. Relationships at FSC require minimal effort and error, defined business processes, and some patience. 

After completing twelve FSC implementations this writing, I can talk about the unique challenges the FSC data model presents and the ideas and best ways how to overcome these challenges. In the first in a small series, we will explore Families and People. 

If you are unfamiliar with FSC or want a quick update on FSC data model and features, check out my first FSC post entitled Getting Started with Financial Services Cloud. 

Personal Account compared to Individual: Choosing the Right Account for Your Customer Account

Just outside the gate, there is a choice. Specifically, how to represent client records. FSC offers two models to choose from, and both have implications. 

The Personal Account model is the preferred model for FSC and is enabled and set as a standard data model for all new FSC components. 

For those who are unfamiliar with the Personal Account, "… store [s] personal information about combining a specific account and contact fields into a single record." (Source) Personal Account records have been around for a long time but have often been a source of frustration for many program managers due to their limitations. However, Salesforce has done an excellent job of developing and supporting Personal Accounts in recent years with the FSC, seemingly finally finding the right home. 

Personal Accounts are good because they are unique records representing both the Account and Contacts which means it has great flexibility in the FSC data model - you can refer to both the Account and Contacts fields. 

Don't forget to check out: What are The Benefits of Salesforce Financial Services Cloud?

The biggest disadvantage of the Personal Account model is that it is often discarded by the AppExchange ecosystem so finding apps that are compatible with Personal Accounts can be difficult. This is where the individual model makes it stand out. 

Oops.  

Financial Services Cloud was released (again) as a Lightning-only product which means that full FSC features only apply to Lightning Experience. At the time of FSC's release, Personal Accounts were not based on the Lightning Experience. Thus, Salesforce has created a Fake Personal Account called Individual. 

Similar to Personal Accounts, Individuals use both Account and Contact records. However, unlike Personal Accounts, they serve as two separate records. The FSC team has worked hard to get Individuals to behave as Personal Accounts through code and verification rules, but they are not the same and they are a royal pain. Here are some barriers to individual modeling: 

FSC comes with a LEX component that redirects users to move from Personal Contacts to Personal Account. Increases navigation and record loading times and may cause some confusion for users. The section can be deleted, but doing so provides users with two different records (Account and Communication) which the user can navigate through which is confusing. 

Creating a Personal Account automatically creates individual Contacts and connects you together (and vice versa). This means you cannot use Individual Contact or personal account. They work together and the setting cannot be closed. 

Creating formulas for personal data requires the use of a special FSC monitoring area called “Primary Contact” that integrates Personal Account and Individual Communication together. 

Displaying related records from Personal Contacts also requires the use of the Main Contact Viewer area (to show Campaign Contact History for example). 

FSC has a custom LEX feature for displaying Account Fields and Links in a single record, but you can't combine account and communication fields together - fields are displayed in two different layout categories. This means that information that can normally be collected can reside in two separate locations on individual records, which require the user to ask. 

Clicking Edit for Personal Account allows users to set up Account fields only - not the Contact fields. You will need to use in-line editing to edit Contact data (assuming the Redirect section of the LEX remains in the individual Contact structure). 

Individual Accounts are not based on the Salesforce duplicate management app. In the event of a duplicate, you will need to use the data uploader to update the parent record and move-related records from duplicate to administrator, and finally delete the duplicate. It's a process. 

The list view that Accounts do not drag in the fields related to Contact unless you create formula fields in the Account, you create additional configurations. 

... many more. 

The individual model is full of obstacles that you will need to overcome if you choose (or are forced into) this model.   

Check out another amazing blog by Rajesh here: Integration Using Named Credentials | Salesforce Developer Guide

Why is this a decision you have to make - especially if the Personal Account model is the default model? 

Feedback comes from third-party applications. There are still a number of important applications that do not support the Personal Account model. Specifically, Portfolio Management Applications such as Tamarac do not currently support Personal Accounts at the time of this writing. (Orion Orion "supports" Personal Accounts but only because they do not actually use them in their compilation).  

Since accounts are the core of the Salesforce data model as a whole, this decision has subtle implications so choosing the right account model is important. However, if you need to use the Individual Model, Salesforce has an upgrade to convert your data into Personal Accounts. If you are forced to become an Individual Model, my suggestion would be to upgrade to Personal Accounts as soon as you can.