7 Tips to Successfully Deploy Salesforce Financial Services Cloud
1. There are two options for getting started
If you are considering purchasing Salesforce’s Financial Services Cloud (FSC), you might be set up in a brand-new instance with FSC pre-installed. If so, great! You will be close to ready to go with any additional configuration or customization as well as general user. If, however, you have an existing Salesforce org, you may need to either install the packages and perform additional setup steps OR start fresh in a new org and migrate data.
- Installing FSC in an existing org
- 👍 Pros:
No need for any data migration, it is already there!
If you already have a complex configuration or automation, you do not need to deploy anything
- 👎 Cons:
Preinstallation, installation, and post installation steps are quite nuanced, so an FSC consultant is recommended for guidance
- Starting fresh with a new FSC org
- 👍 Pros:
There is minimal configuration needed to leverage standard FSC features
You have the opportunity to purge your org of unused or legacy metadata
- 👎 Cons:
You will have to migrate your data and any relevant functionality from your existing instance
2. User configuration is a bit more complex than usual
When first creating a new user with FSC, it is not quite as simple as entering the name and email address as many administrators are accustomed to. FSC is built according to the building block permission principle, which utilizes Permission Sets much more heavily than Profiles. As such, to use many of the specific FSC features, you will need to grant additional permissions to your users.
- Here is a quick list of common permission sets & licenses needed:
- Financial Services Cloud Standard
- Financial Services Cloud Basic
- Financial Services Cloud Extension
- Advisor Access
- Personal Banker Access
- Insurance Access
- Relationship Manager Access
- Aura-Enabled Apex Class Access for Financial Services Cloud
- FSC Insurance
- FSC Analytics Integration
- Use CDS
- Actionable Relationship Center (may need configuring)
3. Person Accounts are not a guarantee
One of the great features available to Salesforce subscribers that have a B2C model is the Person Account. This is especially relevant for several financial services organizations, so FSC comes with Person Accounts pre-enabled. Your ability to use them, however, will depend on several factors.
Are you going to be integrating with any other systems? In wealth management, for example, many firms integrate with a portfolio management tool. Some of these tools do not support the use of Person Accounts in their integrations, so it is a question worth asking when exploring options.
Additionally, the standard FSC data model implies that for B2C operations, Person Accounts would be used together and bundled where appropriate into “group” Accounts, or Households. In contrast, the B2B context would make use of Contacts related to Business Accounts. There is no right answer for all scenarios, but if you do have customers that might be served by both B2C and B2B business units, you likely want to choose a consistent model to avoid duplicate records or information.
4. Ensure intentional input
A common problem with financial services is low data quality. This arises from many different root causes, but ultimately can be addressed in FSC with a few key design elements.
- These elements are:
- Matching and Duplicate Management – This is the most critical strategy for ensuring you do not end up with several representations of the same record in your instance. Consider blocking creation of records when there is a duplicate unique identifier like TIN. In earlier stages of the sales cycle, it becomes more challenging to keep the data clean because you might not have a TIN on file. In those situations you will likely need to present users with existing options if there is a fuzzy match on name combined with a matching city and state, or something similar.
- Minimalist, Logical Data Capture – Everyone acknowledges that a salesperson’s most valuable asset is their time, and time spent cleaning internal data is time not spent selling. It is imperative to minimize the amount of information that requires manual entry, especially by reducing duplicative entry across systems. Additionally, consider leveraging tools like screen flows for logical, wizard-style capture of information, or Paths and Guidance for Success when there are a few key attributes at each stage a record might go through.
- Automate, automate, automate – Consider a field that is used to track the status of a customer record. “Active” indicates that the customer is a revenue-generating client, whereas “Inactive” indicates that the customer is a prospect or a former client. How often do you foresee a user updating this field when a new opportunity closes when the field is on a different record? Or what if a client passes away and the user is already entering a date of death? You can see how quickly this data might become stale or inaccurate if left to manual maintenance. Wherever possible, create simple automation to drive complete and accurate data sets based on your users minimal input.
5. Enable actionable output
With a more reliable database thanks to your sound data capture strategy, you will be able to organize your data in a way that allows for intelligent decision making according to your business needs. Salesforce offers incredibly powerful reporting, dashboarding, and analytical features, but oftentimes the execution of the functionality becomes an afterthought in a brand new implementation.
- A recommended way to address your users’ analytical needs is to implement both a centralized and decentralized model.
- Centralized – Task a specific user or team of users with the responsibility of developing and owning common reports and dashboards to be used company-wide. This suite will serve as a measuring stick and thread commonalities between uncommon business units in a way that allows upper management to discern and decide moving forward.
- Decentralized – Allow users to create their own basic reports and dashboards for use, coupled with adequate training. In a given organization no two leaders or individual contributors will have 100% identical desired views, decision points, etc., so this structure allows a user to answer the questions they are curious about, in turn rewarding them for their own clean input of data.
6. Challenge all security requirements
In financial services organizations with multiple revenue streams like a retail and commercial bank, there are often regulations or leaders that will require some level of CRUD (create, read, update, delete) restriction on users that do not directly work for the business unit that owns the data. For example, a commercial region manager may state that all activities his bankers have with clients should be hidden from retail employees.
On the surface, that is a requirement, and a solution could be developed for it. But it is critical to understand the “why” behind the requirement, especially because it defies the “customer 360” attitude that allows for employees to best serve clients. Perhaps the request is due to the business model, which attributes revenue to the commercial bank if certain retail opportunities are identified and closed. Perhaps it is not a blanket “all activities” requirement but is that meetings about certain topics (such as mergers and acquisitions) need to be kept private due to regulatory restrictions.
💡One of these is a valid requirement and the other is not, but it is also important to challenge the “regulatory” claim, as it is often used to explain away a question that might not have a definitive answer.
7. Challenge all transactional requirements
Insights drawn from and automation triggered off Financial Account Transaction data are often some of the most sought-after, exciting features in the minds of FSC end users. There unfortunately is also a universal issue when it comes to transactional data, which is storage.
How can any one organization continually archive and analyze millions and millions of records without incurring incredible costs for consuming space?
If your team is comfortable with a limited history, you may be able to swing a “recent transactions” strategy where the data does live in Salesforce but is rapidly archived depending on client and transaction volume. More appropriately you may build your strategy around data virtualization, which is an integration method that represents data from another system in Salesforce rather than consuming much of your valuable cloud storage space.
The major obstacle that most financial services organizations face in this situation is the additional licensure cost needed for the data virtualization option (Salesforce Connect). SMBs may be tempted to simply store transactions directly in Salesforce to avoid that cost, but even smaller firms will have large numbers of transactions over time and be faced with the potential of additional storage. In this situation, either regular archival or the Alerts API may have to suffice, which allows notifications/actions to happen within Salesforce based on external transactional data and is a feature included with FSC.