The third article of our Salesforce FSC (Financial Services Cloud) series continues on the topic of Financial Modelling and looks into Application Management. The main focus here will be for the users – financial institution’s employees rather than its customers, so we won’t delve into Experience Cloud. There is however an underlying assumption that you will use Salesforce for application orchestration and expose out to customers in whatever means you choose.
As previously covered, FSC pretty much models all financial products as Financial Accounts, with a couple of notable exceptions. We also have the existing standard objects in Leads and Opportunities (with some custom fields specific to FSC added to these objects) that we can use to model potential financial needs of the customer. What is not included out of the box, is a set of tools that converts that Opportunity into a Financial Account and manages that journey around product origination.
There is a caveat to this in that for Mortgages there is a full data model and the ability to convert a Residential Loan Application into a Financial Account. Couple of things to note:
Using this function beyond Mortgages for other products would in itself require heavy customisation and extend it far beyond its intent, so it is not, in this authors view, a valid option.
There are also 3rd party products that handle the equivalent of this journey in their own way (nCino, Sageworks, Q2 etc) and we will review those products in more detail in a future analysis (after the completion of this initial series) as they are generally significant packages and cover the length and breadth of sales, underwriting and service.
That then leaves us with custom build. So, getting from an initially identified potential financial need to an actual Financial Account may not be out of the box, but it is straight forward to string together the Lead>Opportunity>Financial Account journey. Your choices will be around how you model the application journey, and specifically, whether you choose to stick with Opportunity and line items or you use a custom object. Given the varying requirements and processes that each product line will follow (and the amount of data needing to be captured) then it is highly likely you will need to go down the custom “Application” object route.
This is reinforced by the need to keep the Application as a snapshot in time versus the “living” version of items such as income, expenditure, assets and liabilities. This is because any given application will need to be kept intact in an audited form that becomes non-editable once complete, so you always have access to what was actually submitted at the time.
Once we have our custom object we can easily create relationships to both an Opportunity and to Financial Account and bridge the gap in the end to end process.
You will then need to extend out the remainder of the data model for Application, however you already have a sensible structure for this to leverage in the form of the aforementioned Mortgages model and I’d recommend using that general model as it keeps you aligned with Salesforce’s approach and if they do bring in a standard model for this it would be likely to follow that same pattern so transitioning to it would be less painful.
Once we have a structure for our application in place, we can then look at building our user journey out and integrating into product, pricing, credit scoring, fraud and all the other processes that go beyond simple data capture and into the actual decisioning of the application.
More on that next time!
If you would like to find out more about how Salesforce Financial Services Cloud can help optimise employee productivity and customer experience, give us a call or email us at salesforce@coforge.com.