Learning Objectives
After completing this unit, you’ll be able to:
- List the key attributes of a typical insurance policy.
- Understand the data model behind coverage details.
- Explain the approach to modeling payment information.
- Describe how the insurance data model supports a workers’ compensation policy.
Basics of an Insurance Policy
The insurance data model brings all the information related to insurance policies and claim summaries to Salesforce, so you have a 360-degree view of your policyholders. Let’s see how Cumulus does this with one of its policyholders.
Anna Murphy is a longstanding, high-net-worth customer of Cumulus, and she has several relationships with the company. She recently purchased a car insurance policy for her sedan from Cumulus.
Some policy attributes follow.
| Attribute | Value |
|---|---|
| Policy Type | Auto Policy |
| Policy Term | 1 year |
| Original Effective Date | Jan 1, 2022 |
| Original Expiration Date | Dec 31, 2022 |
| Premium Amount | $1000 |
If you’ve earned the Financial Services Cloud Data Modeling badge, you know that Anna Murphy is modeled as a Person Account and Policy Participant.
Person Accounts store information about individual people by combining certain account and contact fields into a single record. Person Accounts let you store information that applies to human beings rather than corporations, such as a first name and a last name.
Key Objects
But how does Justus adapt the insurance data model to represent Anna’s car insurance policy? The following objects capture the key details of her account and insurance policy.
This table describes each object and its connections in the diagram.
| Object | Description |
|---|---|
| Account | The Account object (1) is a standard Salesforce object. Multiple Account types are available for businesses and consumers. Account objects have a parent-child relationship, which means you can nest accounts. This is useful for businesses because the business can have client accounts within their business account. Anna has a client account. |
| Contact | Each person related to the account should have a single Contact record (2). Contacts and accounts have a direct relationship, so the Contact object holds a many-to-many relationship with the Account object. Every contact identifies the primary account directly related to it. Anna and Nigel Murphy, Anna’s husband, both have a Contact record. |
| Insurance Policy | Think of the Insurance Policy (3) as the root object in the insurance data model. Everything else flows from here. The Insurance Policy object is a specific configuration of the product model and is based on policyholder characteristics. Insurance Policy records capture essential information, such as the policy number and type, name of the insured, effective dates, and applicable premium. Agents use Insurance Policy records to track the policies of their customers and lookups to carrier accounts. Each policy can have only one account, but one account can have multiple contacts and policy participants. Insurance policy participants can be owners, drivers, or beneficiaries. We dive into policy participants later. Anna has life, car, and homeowners insurance with Cumulus, but for this example, we focus on her car insurance policy. |
Policy Coverage
Zeynep, our all-star sales agent, originally sold Anna her car insurance policy. Now he reaches out to Justus Pardo, a consultant for Cumulus, to map the details of Anna’s policy to the Salesforce insurance data model.
The insurance data model is versatile. You can update it to add records and details for a person’s major life events. The insurance data model organizes clusters of data, like Anna’s, so Cumulus can work cohesively and efficiently.
Here’s how all the information and interconnections play out visually.
This table describes how the data model organizes all the information.
| Object | Description |
|---|---|
| Product | The product model connects to the data model as the Product object (1). The product model is a structured definition of a product that a company sells. In our case, product models serve as the blueprint for each Cumulus Insurance type. The Product object is made up of specification or spec records. The Product record or spec types represent coverages (Coverage Spec), people (Insured Party Spec), and things (Insured Item Spec). Many data model objects connect to the Product object to retrieve spec data. Every coverage, insurance policy asset, and participant record is tied to the corresponding type of product spec. You can bring the master list of coverages into the product model and then use the Policy Coverage object to model the coverages purchased under specific policies. |
| Insurance Policy | Use the Insurance Policy object (2) as the root object for Anna’s car insurance policy. This policy has multiple Policy Participants, insurance policy assets, and policy coverages. All have key relationships. The product model supplies Insurance Policy with attributes. |
| Policy Coverage | Anna’s car policy includes Comprehensive, Collision, and Personal injury coverage. The collision damage coverage includes a liability limit of $50,000 to cover damages and a personal deductible of $500. Policy Coverage records (3) store this information. A policy, participant, and insurance policy asset can have multiple policy coverages. |
| Insurance Policy Asset | Anna’s sedan is currently her only insurance policy asset, but thanks to a recent bonus from work, she decides to reward herself with a brand-new SUV. She wants Cumulus to cover the new car under the existing policy, but she wants to change some details. Namely, she wants comprehensive coverage for the SUV, but not the sedan. Cumulus adds an Insurance Policy Asset record (4) and adjusts Anna’s policy coverage. This record contains high-level information on her new SUV insured by the policy. |
| Insurance Policy Participant | Anna wants to include her husband, Nigel, on the car insurance policy. Nigel does weekend grocery runs with Anna’s sedan, so she wants to make sure he’s covered. Like Anna, a Person Account models him in Salesforce. Justus uses an Insurance Policy Participant record (5) to relate him to Anna’s policy as a driver. Insurance policy participants can be owners, drivers, or beneficiaries. |
Life Insurance and Securities
Zeynep logs in to his insurance agent console on Monday morning only to see a dashboard alert. It reminds him that it’s Anna’s 30th birthday in a few days. Zeynep, ever the sales rockstar, uses this opportunity to cross-sell a new life insurance policy to Anna. Anna appreciates Zeynep’s proactiveness: She buys an asset-backed life insurance policy from Cumulus.
The following model represents Anna’s new Cumulus life insurance policy.
Anna’s Insurance Policy (1) protects life while allowing Anna to invest in market securities such as stocks and bonds. Anna chooses the US Equity Large Growth investment fund option. Her new investment is now a Security Holding record (2) tied to Anna’s account (3) and Life Insurance Policy (1). She nominates her husband Nigel as the policy beneficiary (4). Let’s admire Justus’s handiwork on this one.
The Payment
Anna wants to pay the life insurance policy premium on a quarterly basis through her primary Cumulus account. Here’s how Justus models Anna’s life insurance policy financial account information.
Justus uses custom objects to represent financial accounts. These objects hold information for transactions, payment methods, and financial accounts. For Anna, this includes her Debit life insurance premium payments, Cumulus account information, and Life Insurance billing statements. Let’s see how the information plays out.
| Object | Description |
|---|---|
| Insurance Policy | The Insurance Policy object (1) is the root object for Anna’s life insurance policy billing. Anna’s life insurance policy connects to her billing statements, payment method, and financial transactions, but it doesn’t connect to her financial account. |
| Financial Transaction | The Financial Transaction object (2) includes records of the transactions that take place on Anna’s life insurance policy. Each transaction record is specific to one financial account and insurance policy. A transaction can be debit or credit. |
| Policy Payment Method | The Policy Payment Method (3) recognizes which account the customer uses for the payment, while the financial account records store the information for that account. Anna’s Cumulus Account is her primary Policy Payment Method for paying her life insurance premiums. |
| Financial Account | A Financial Accountrecord (4) stores Anna’s Cumulus account information. |
| Billing Statement | Anna has multiple Billing Statement records (5) for her Cumulus account and Life Insurance policy. Each record is a summary of purchases, deposits, interest, fees, and charges against an account. |
Insurance for Employers
Anna’s employer purchases a workers’ compensation policy to cover expenses that arise from any accidents. A workers’ compensation policy typically covers different classes of employees at different business locations. Here is how Justus models a policy.
This table describes how the insurance data model organizes the data for workers’ compensation insurance policies.
| Object | Description |
|---|---|
| Insurance Policy | Anna’s employer now has an Insurance Policyrecord (1) for a Workers’ Compensation policy. |
| Policy Coverage | A Policy Coverage object (2) stores the coverage information from the workers’ compensation policy. A policy can have multiple policy coverages. A single workers’ compensation Policy Coverage connects to many Workers’ Compensation Coverage Classes. |
| Workers Compensation Coverage Class | A workers’ compensation policy typically covers different classes of employees at different locations. Each class of employees has its own Workers Compensation Coverage Class record (3). |
Now that you've learned about Anna’s insurance policy data model, head to the next unit to learn how Cumulus organizes Cloud Kicks’s quote and contract data for group insurance.
Resources
- Trailhead: Financial Services Cloud Data Modeling
- Salesforce Developers: Financial Services Cloud Developer Guide
- Salesforce Developers: The Salesforce Data Model for Financial Services Cloud
