One of the best things about being a consultant is that I get to play with new Salesforce functionality that I wouldn’t otherwise be able to experience. As Salesforce continues to expand its reach with more vertical market solutions, an entirely new series of Salesforce functionality enters the community. Today, that’s Financial Services Cloud.
Financial Services Cloud (also known as FSC) has been around for a couple of years now, and is similar to the concept of the Non-Profit Starter Pack, except that the configuration focuses on the Financial Services sector. FSC is an installed application, and only available in Lightning Experience.
The intent of FSC is to allow companies such as wealth management and investment firms, banks, and other financial institutions to manage their clients and client assets, liabilities, financial accounts, and much more. While the overall data model is pretty easy to understand, there is one element of FSC that threw me for a loop – Accounts.
Let’s dig into the data model, and I’ll explain a bit more.
The Data Model
Financial Services Cloud is still an account-centric data model. However, the way that FSC goes about representing these clients can be a bit confusing. Let me first start by outlining the types of accounts.
- Individual – this account record type represents a person client. For example, if you were a client of a financial planner or wealth advisor (or even a customer of a bank), you would have an Individual account.
- Institution – this account record type represents a business client. The example would be your employer. If your employer offers a 401(k), then your employer would be an Institution.
- Household – this record type is a grouping mechanism to group multiple Individual accounts under one roof (no pun intended). It allows advisors to attribute numerous Individuals to a household, and to roll up the assets and other calculated values to the household (things like AUM – assets under management, and tasks among other calculations.
- Business – this record type is a standard Salesforce account. It doesn’t perform any specific or unique functions. It houses accounts such as a CPA firm, or Attorney.
While all of this seems straightforward, the data mode is a bit confusing (but you wouldn’t know it was looking at the data model), so I’ll explain the account structure in a bit more detail.
Individual Client Account
Financial Services Cloud does not currently use Person Accounts (but they will fully support person accounts as the preferred model in the Spring ’18 release). Instead, FSC leverages the magic of Lightning Experience and some standard Admin level wizardry to create a person account type entity in the Individual.
When an advisor creates an Individual account record, a trigger creates a contact record with the same record type (also called Individual). These two records link together using an Individual ID. This ID is specific to the relationship between the account and Contact record. The same is also true if the advisor creates a contact with the record type of Individual – an Individual account is created via this trigger, and the two records are associated together.
This creates the person account-like functionality, but instead of managing one record, you now have two. But, that’s where the magic of Lightning Experience comes into play!
Should an advisor choose to navigate to the Invidiaul account record, they will be presented with account level detail, as well as contact level detail, thanks to the use of some Financial Services Cloud specific Lightning Components. Here’s a screenshot from an example Individual record.
The details section is one custom component, but it’s broken up into an Account Details section (which is not in this screenshot) and Contact Details section which includes all of the information from the Contact record. Both sections are editable from the account object.
Confusing things further, there is a setting that will redirect users to the Account if they click on the Contact from a search result or a Lookup field from another record, but that behavior is meant to enforce making edits to a single record.
The Financial Accounts tab on the Individual and Institution record include related lists – specifically the financial assets and liabilities owned by the client.
The Financial Summary section at the top of the page is a custom Lightning Component that rolls up all of the information in the Financial Account related lists. It does a great job of housing all of the accounts related to the client in one place and providing a quick overview of the client’s financial picture (even for accounts that are not under management).
Financial Services is a relational industry. It’s important to track every type of relationship between clients, non-clients, and how they all work together. The Relationships tab allows advisors to see how other clients and non-clients relate to one another and allows for management of those relationships. Thanks to the power of Lightning Experience, we can visualize these relationships in a pretty neat way!
In this example, my Individual client account record is showing a relationship to Laura, my wife. We’re both members of the Downey Family household. Also, advisors can indicate related accounts (like if I own my own business, or were a board member for a company, that would be listed as a Related Account. Related Contacts would indicate things like a client’s CPA, Attorney, or other related contact servicing the account.
Did you notice the roll-up section below? It is a snapshot of the household members along with their relevant information. So in one snapshot, I can see relevant contact information, the Last and Next Interactions, and a roll-up of the count of activities for each.
It’s super easy to roll up this information. By clicking on the +Add Relationship button in the tree view, a modal will open and allow advisors to manage all three of the relationship types. Here’s an example using the above account.
This modal makes things super easy to manage, and it automatically creates relationships or updates relationships after hitting Save. It saves the agent from having to make multiple clicks throughout the Org.
The Household record that I created in this step is an aggregating record type on the account object. The goal of the Household account is to aggregate assets, liabilities, goals, and activities of household members. Keep in mind that each household member can have their assets (like a 401(k) for example) in addition to joint accounts. This grouping mechanism calculates the total Household value, as well as the interactions with the clients.
Here’s how the Downey Family Household looks. It only contains high-level rollup data.
When clicking on the Financial Accounts, Relationships, Goals, and Related tabs on the Household record, you’ll see the aggregated information from all Household members for quick and easy navigation of records related to the Household.
Everyone has financial goals and dreams, and it’s a financial or wealth advisors job to ensure that they help their clients reach those goals. Financial Services Cloud allows advisors to track client’s progress towards their defined goals as part of their financial planning. Here’s an example of what goals looks like (using some excellent Lightning Components again)!
This screenshot is from the Household, but goals can be maintained and managed at the Individual or Institution record only, and not rolled up to the Household.
Financial Service Cloud Considerations
I’ve been working with Financial Services Cloud for a little over a year now, and there are some things that Admins and Consultants should consider. Here are a couple of items that I’ve learned along the way.
Lightning Experience Only
Financial Services Cloud requires that users are in Lightning Experience. If you are not using Lightning Experience, the vast majority of the underlying FSC functionality won’t work. Data will not look accurate, and users will be frustrated. If you’re going to pay for the feature, you should use it as intended.
One of the first steps in implementing Financial Services Cloud is to ensure that My Domain is enabled and deployed for the Org. The vast majority of FSC functionality drives off of custom Lightning components which require that My Domain is activated. This is a requirement.
I’ve actually seen instances where consultants didn’t understand the data model well and the data was loaded incorrectly. Just like with any data migration or import, it’s important to understand the data model and the order of operations needed to import data. But, FSC adds some extra complexity to the data model around the Account structure (as we’ve seen above). If the Individual records are not defined and imported correctly (i.e., you only need to create the Individual Account or Contact record – not both), you could end up with duplicates or very messy data.
FSC Managed Package
FSC is similar to the Non-Profit Starter Pack in that it’s a managed package. While the package updates with each Salesforce release, not all features auto activate. It’s vital that Admins and Consultants working with FSC clients are aware of this, and take the time to review what is coming out in the release, and what if any are required manual updates. Yes, some manual updates must take place. If these updates do not take place, some pieces of FSC can break.
Additionally, there are limitations to manage packages that are at play here with FSC. For example, I had a client who wanted to change the field labels for some fields on the Financial Account object. Because the fields are part of a managed package, I was unable to rename the field labels. The natural next step would be to create new fields on the object to mimic what the field is doing, but call it something different. However, this presented a few problems:
Problem 1: IT’S NOT A BEST PRACTICE! – Creating entirely new fields to replace standard fields is not a best practice at all. It may seem inconvenient to use what is provided but will save you time and money in the long run.
Problem 2: Standard Functionality Suffers – FSC and Salesforce at large have a lot of standard functionality that operates from the standard fields. What I found out was that even some of the seemingly benign fields on the Financial Account had an impact on how data rolled up to the account. There is a lot of behind the scenes functionality in FSC and messing with these standard fields can cause problems.
There is one workaround that could be leveraged if the field labels absolutely need to be renamed, and that is to leverage Translation Workbench to modify the field label (thanks to James B. for pointing that out in the post comments). Regardless, ensure that you’re regularly updating your installed package with each release and that you always start by using the standard fields provided by Salesforce.
We packed a lot into this post today. I know you probably want to know what comes next! Well, I’ve thought of that! Let’s start with everyone’s favorite – Trailhead! There is a Trail currently available which I’ve added to a custom Trailmix. I’ll continue to add to the Trailmix as more FSC modules become available. Click on the image below to hit the trails!
Implementation & Upgrade Resources
Next, I highly suggest that you read through the implementation guide. And by “read through” I don’t mean skim. I mean read. Honestly, this is one implementation guide that I have read through from start to finish several times. Every time I do, I learn something new. Get your highlighters ready – you’re going to need them! Here are all of the documents you’ll need to review.
- FSC Trial Org – play with FSC for free for 30 days
- Installation Guide
- Quick Start Guide
- Administration Guide
- Post-Upgrade Tasks
There are a few groups in the Success Community that you should consider joining if you haven’t already.
The user group is a virtual group and has a lot of content. The second group is run by the Financial Services Cloud group at Salesforce. I highly encourage you to join both! If you’re a partner, there are some FSC groups in the Partner Community as well, and they provide some vast resources that are partner-specific.