A lot has changed since Salesforce first released Financial Services Cloud (FSC) in 2015. At first it was primarily a standardized data model with a couple of lightning web components to help illustrate relationships and an advisor’s daily view. Salesforce has iterated on it in the years since and added a host of new functionality, including (but not limited to) advanced relationship center, record rollups, compliant data sharing, financial deals, and data models to support different industries in financial services. Let’s get into the details: what FSC provides, how to approach an implementation, and what your next steps should be if considering an FSC migration.
FSC: What is it? Why use it?
FSC was born because the existing Sales Cloud and Service Cloud did not meet the exact needs of financial services companies. Salesforce discussed these requirements with various market-leading institutions and out of those discussions, this industry cloud was created. Depending on your specific financial services industry, you will be looking at: banking, insurance, or wealth and asset management. Each of these products do provide some extra features tailored to their specific use cases, which will be covered later. For now, let us focus on features that are common across all three.
Common Data Model
One of the core components of FSC is its common data model. This flexible and scalable model has been designed to specifically meet the needs of the financial services industry. This core data model can then be augmented with specific models for insurance and/or mortgages based on your industry. It starts with the standard Salesforce objects and then layers on a number of objects to support various account-contact, account-account, and finally contact-contact relationships that are used in wealth management.
These objects are all there to support the householding, group membership and actionable relationship center features. With them you can detail out how a contact and/or account fits in with a web of relationships that can be as simple as a single family household or as complex as a large organization.
Naturally, a component of FSC will be devoted to modeling out the financial accounts, assets/liabilities, and financial holdings of your customers. There is the ability to relate multiple accounts to multiple financial accounts with the financial account role object. Depending on your requirements cards, transactions, statements, and even billing are available to be included in your implementation. A couple of other highlights of the data model are the objects needed to support action plans, interaction logs, life events, and financial deals.
Householding, Group Membership, and ARC
One of the primary features of FSC is simplifying the complexity around householding and group membership. Out-of-the-box FSC provides a number of custom components and the supporting data model for your users to represent their customers’ complex relationships. It has the capability to summarize data from the child records at this household/group level which can be configured to meet your specific requirements. Adding and removing group memberships is straightforward and handled through a component that is included as part of FSC. When reviewing a household the UI helps illustrate the complex web of relationships that a single customer can entail. However, if you need to take more actions than just representing the relationships and viewing summarized data, then the Actionable Relationship Center (ARC) is what you are looking for.
With the ARC you can not only see the relationships between households and groups, but also for child objects like opportunities, cases, financial accounts, loans, insurance policies, etc. As of the summer ‘22 release it’s highly configurable to show whichever related records make the most sense for your business. Now can you create multiple ARC graphs with a drag-and-drop editor (similar to the flow designer) depending on how you need to view that particular customer’s relationships. It also affords the ability to take actions on those records — for example, creating a new case or opportunity off of a related contact (hence the “actionable” part of the name). These actions are configurable, so they could be as simple as just creating a related record to kicking off a flow to orchestrate a complicated business process. One thing to note is that ARC is only available if you are using person accounts.
Action Plans
A number of banking processes are all around a defined set of actions that need to be managed by an individual. For example, when onboarding a customer for applying for a mortgage the same set of steps and documents need to be requested, reviewed, and approved. Action plans provide a simple way of managing these common sets of tasks. It provides an admin with the ability to create an action plan template which includes the set of tasks and/or documents needed. When defining a template you can specify a task, who it’s assigned to (i.e., the creator of the plan, a specific user or a role on account, case or opportunity teams, or a queue), and even set a dependency. For example, if a task involves receiving accurate banking statements you might have a dependent task that is assigned to your underwriting department queue to review those statements.
Action plans are now able to be associated with many standard objects and custom objects. They are also available in flows, process builder, and triggers, which allows you to perform even more complex business logic if needed.
Interaction Summaries
This feature allows your users to take detailed meeting notes, add action items or next steps, and specify the confidentiality of those notes. Previously the event object existed for this use case, but Salesforce has created a new model to support the more complicated sharing requirements that financial institutions may have. Interaction Summaries have a straightforward UI for adding attendees and taking structured/compliant notes about a particular interaction. The summaries also come with a component that can be used to easily search, so users can find the right information about past interactions more quickly. For example, when on an account you can easily select a specific contact and have all the interactions for that contact shown.
Interest Tagging
If your users have ever needed the ability to capture specific interests for a client — for example, if you wanted to tag which stocks and/or personal interests a particular customer has — then interest tagging is the right feature to use. These are not freeform values, so as an organization you would need to define a taxonomy of interests and their categories (e.g., music preferences vs. investment tools vs. hobbies). Once that has been completed, users can then select as many interests as needed and associate them to their client records. It’s another flexible way of tagging particular information to a client to support a “white glove” approach for your next interaction.
The right approach to evaluating FSC, especially if you already have Salesforce
When you are evaluating whether FSC is right for your business, the most challenging decision is based on whether you already have Salesforce in use at your organization.
If you do, then you will need to determine if you will implement FSC “brownfield” or “greenfield.” These terms are defined as either implementing FSC in an existing Salesforce org (i.e., “brownfield”) or determining if you should start fresh and implement a brand new org with FSC (i.e., “greenfield”). There are several factors to consider with both approaches. If your organization does not use salesforce currently then this is a moot point; it will be greenfield, but the same consideration for the implementation will be useful.
Brownfield vs. greenfield
The general approach to determining brownfield vs greenfield is as follows.
Evaluate the current business processes and use cases that exist within your Salesforce org:
- Evaluate the current data model
- Evaluate the current customizations and configuration tied to those processes
- If Retail Banking or Wealth, then run the FSC Transition Assistant (details below)
Overlay the FSC feature set on the current business processes and identify the overlaps and gaps.
- Overlaps would include:
- Data model differences
- Business process differences
- Existing customizations that would need to be rebuilt and/or retired
- Gaps would include:
- Missing data model in FSC
- Missing business processes not included in FSC
- Customizations that are not available in FSC
After identifying the gaps, the next step would be to look at what else would be affected based on your approach.
Greenfield:
- Existing customizations and configuration that needs to be migrated that has no relationship to FSC
- What data will need to be migrated
- Timeline to implement FSC and customize as needed
- Other considerations: integrations that would need to be migrated, basic org setup, user migration, SSO configuration
Brownfield:
- What could be retired/deleted from the org
- Any data that needs to be migrated/modeled differently based on FSC data model
- Existing integrations
FSC Transition Assistant
The FSC Transition Assistant is a tool designed to simplify the planning and execution of your migration from Sales Cloud or Service Cloud to FSC within an org. It provides early insights into what an FSC transition entails, shortens timelines for analyzing your current org’s complexity and overlap with FSC features. It does the heavy lifting of discovery and mapping. It requires filling out a guided questionnaire that helps it understand your org, then it maps objects, record types, and fields to FSC, ultimately generating an assessment report with recommendations and a prioritized roadmap.
In the end, this process is an output that will recommend whether you should be executing a “greenfield” or “brownfield” strategy for your org. After reviewing the recommendations and strategy, there is the ability to automate part of the effort — namely metadata changes like page layouts, validation rules, profile field-level security, and compact layouts. The UI gives you the ability to select what to deploy and it will automatically build the deployment package and deploy to your org. Note: This only works for Retail Banking or Wealth.
Get expert support for your FSC migration
Our team at Atrium takes a data-driven approach to implementation, to surface insights that financial firms can use to prioritize and take action in real time. The migration from Sales Cloud or Service Cloud to FSC is an opportunity to create long-term value. We have years of experience supporting financial services businesses in banking, insurance, mortgage, wealth, and beyond make the switch.
Learn more about Salesforce Financial Services Cloud and how we can support you through a migration.
