It is no secret that within the Salesforce ecosystem, and generally regarding CRM technology, industry experience and wisdom must be apparent in order to merit the attention of organizations looking to transform digitally. Salesforce has an excellent track record of drawing from various fonts of knowledge given its heightened focus on providing industry-specific functionality. Perhaps one of the strongest and most beloved features of Salesforce Financial Services Cloud (FSC) is its industry-specific data model that addresses many of the nuances within each of the financial services verticals that the product serves.
As with any technology, however, striking the balance of what makes sense within the platform vs. what makes logical business sense can be incredibly difficult. One of the more challenging areas within FSC that, on the surface seems incredibly overengineered, is Insurance, evidenced by the FSC Administrator Guide entity relationship diagram (ERD) pictured below. How in the world can we make sense of this “spaghetti mess”?
It All Starts with the Core Objects
It is easy to get overwhelmed when you are tasked with helping your insurance firm or client implement FSC and you open this image for the first time. Take a deep breath, set the intimidation factor aside, and start analyzing the data model as you would with even the smallest ERD – identify the core objects from the business perspective, and then locate them on the ERD.
Within the Insurance industry, which almost everyone has a general level of familiarity with given the common products of health, home, life, and car insurance, we know of a few major players. Take a massive company like Geico, which promises to save you 15% by just taking 15 minutes to switch over to their coverage. In this scenario, Geico is likely the Salesforce customer, whose employees are Salesforce Users.
Now imagine you as a consumer inquire with Geico about this savings claim. You have become one of their Contact records in FSC, given that you are a prospective client. Taking it a step further, you decide that you will get more value out of insuring with Geico, so you sign up with them to cover your car. You have now entered an agreement for an Insurance Policy.
All is fine and good, and you are happy with your newly found savings, but unfortunately the following month you end up in a fender bender. You confirm everyone involved is okay, take out your mobile phone, snap a few pictures of the damage, and open a Claim with Geico, who logs the information within Salesforce.
Is this example an oversimplification of what FSC offers? The short answer is yes – but now we have identified the core objects that we care about: Contacts (with their respective Accounts), Insurance Policies, and Claims, essentially from which the rest of the Insurance data model flows. Other than a few other standard & junction objects (which allow many-to-many relationships between other objects), many pieces of the data model are even more specific to verticals within Insurance, such as the ability to indicate which coverage class a worker falls into under a workers compensation policy, which is obviously only applicable if your firm or client offers workers compensation insurance.
Layering in FSC’s Households and Person Accounts
As comes enabled with all new instances of FSC, Person Accounts are especially useful for financial services organizations that operate in a B2C model, as is the case with many companies in insurance. FSC takes the standard Salesforce Person Account functionality a step further by allowing administrators to configure group record types, of which the Household record type comes standard with FSC. The Household essentially serves as a container and an aggregator for all the Person Accounts that belong within it.
Continuing with our Geico auto insurance example, you would exist as a Person Account (rather than Contact) and be linked to your Household. Your spouse would also be linked to the same Household as a separate Person Account. You may or may not both own or both be insured for each of the family cars – one minivan and one sedan.
For this illustration, let us assume you are both titled and insured for the minivan, but only you are listed on the title and insurance policy for the sedan. Geico will record this in Salesforce by logging you as an Insurance Policy Participant for both automobiles, but your spouse will only be logged as an Insurance Policy Participant for the minivan. Thanks to the powerful data model FSC gives us with Households and Person Accounts, Geico employees will be able to see that both Insurance Policies are related to your Household, both apply to your Person Account, but only one applies to your spouse’s Person Account. This leaves no question as to who is covered by or financially responsible for which policy!
Junction Objects Galore
Now that we have investigated the core insurance objects and how insurance fits into FSC’s relationship-based data model, we are ready to tackle some of the ancillary tables that help us create many-to-many relationships between major objects, which we refer to as junction objects. Before we dive in more deeply, pictured below is a prime example of a junction object in the context of FSC’s Households and Person Accounts. The mechanism to indicate which group a person belongs to is the Account Contact Relationship, which is essentially one row in a table that stores the Household ID and the Person Account ID.
In the larger Insurance ERD, you will notice several of these junction objects that have two “crow’s feet” linking between two generally more significant objects (in this case, Account and Person Account). Here are some highlights of junction objects in that data model:
a) Insurance Policy Participant
As mentioned previously, this object will link your Person Accounts/Contacts and Insurance Policies, primarily to indicate who the insured parties are.
b) Claim Participant
Like Insurance Policy Participant, this object links Person Accounts/Contacts to Claim records when one is opened against an Insurance Policy.
c) Insurance Policy Asset
This object is not as straightforward, as there is another related object, Customer Property, that has a one-to-one relationship with the standard Asset object. It essentially enables the linking of insured possessions to an Insurance Policy, such as a house or a car.
d) Insurance Claim Asset
Link Insurance Policy Asset, this object links your insured possession to a Claim. For example when you got in that fender bender, your damaged vehicle and Claim are linked via the Insurance Claim Asset.
e) Insurance Policy Coverage
This object is a more detailed link between your Insurance Policy Assets and your Insurance Policy, allowing you to indicate additional information about the type of coverage on a policy. In the Geico example, this may include both collision and comprehensive auto insurance.
f) Claim Coverage
Like Insurance Policy Coverage, this allows you to specify details such as the collision coverage you have is what will be used to cover your fender bender Claim.
g) Producer Policy Assignment
This object links your agents to the appropriate Insurance Policies that they sell or support.
h) Producer Commission
This object links several other objects, but primarily serves as a way to track dollar amounts earned by Producers related to Insurance Policy Transactions.
i) Product Coverage
This object enables you to indicate which Product is related to which Insurance Policy via a few additional objects, assuming you use Products during your sales cycle. It is an excellent way to bridge the gap between sales and service.
j) Financial Transaction
Normally just a child object of Financial Account in FSC, within Insurance the Financial Transaction serves as an interesting additional link between an Insurance Policy and its child Claims. When a transaction represents a payout for a Claim, it can be recorded against both that Claim and the Insurance Policy itself.
While there are a handful of other junction objects pictured, these are likely the most heavily used and should assist with connecting the dots for others that might be leveraged based on your business requirements.
In Summary
While the data model for Salesforce FSC Insurance is complex on the surface, it can be compartmentalized into much more easily digested sections based on the needs of your firm or client.
Conclusion: So above is the Understanding the Salesforce Financial Services Cloud Insurance Data Model article. Hopefully with this article you can help you in life, always follow and read our good articles on the website: W Tài Liệu
