Deep Dive: Salesforce Industries for Insurance

This is the second part of a series that started with Introduction to Salesforce Industries and OmniStudio. That first post provided an overview of the Salesforce Industries solutions and OmniStudio platform — a robust suite of 100% native, task-based components (OmniScript, DataRaptor, Integration Procedure, and FlexCards) that give you the ability to offer a combination of core and industry-specific processes and solutions.

In this post, we take a real-world industry example and provide guidance on how the Salesforce Industries solutions can help accelerate a digital transformation.

Content last updated in April 2021. Roadmap corresponds to Summer ’21 projections. Our forward-looking statement applies to roadmap projections.

Specifically, we will explore how the Salesforce Industries Insurance solution streamlines requirements gathering while speeding the delivery of value to the business. In this post, we will discuss how you can use Salesforce Industries solutions to create and sell products with a rating engine to price them; and in a future post you will use the insurance solution’s data model, service layer, and UX components along with tools from the OmniStudio platform to create deployable user experiences and business processes like Quote, Rate, Issue Policy, Endorse (amend or make midterm adjustments), Renew, and Claims.

We have a ton of stuff to go through, so grab a cuppa and read on.

Data model

Salesforce Industries has extended the Salesforce standard object model to include a deep insurance data model. This industry-specific data model can help you reduce the cost to serve and accelerate time to value. Standardizing on a single industry specific data model across business units will also help provide the basis for a strong governance program.

Here, you can see that the Industries solution does not re-invent the wheel and instead makes use of standard objects where possible.

These are the standard objects that the Salesforce Industries model has extended extensively at a high level; Accounts, Contacts, Products, and Price Books are used frequently across different industries.

Both Business Accounts and Person Accounts are supported in the Insurance and Healthcare & Life Sciences package. In almost all use cases, Person Accounts are the ideal choice to represent the insured customers, members, or beneficiaries. To track agencies that sell insurance and other intermediaries, you’d use the Business Accounts and related Contacts.

Here is a snapshot of the Policy Management data model for FSC Insurance.

I won’t go into all of the objects in this post (otherwise, we’ll be here all day), but to whet your appetite, I will describe a few top-level entities supported by the data model and highlighted by the icon in the box.

Insurance Policy
An Insured Policy represents a policy (previously known as Held Product or Service) that covers the insured and optional beneficiaries).

Policy Coverage
Represents the benefits of the policy

Insurance Policy Participant
Represents people covered by the policy

Insured Item
Represents the insured items

Apart from Customer and Quote/Policy management, the enhanced data model also covers Billing and Payments, Quoting, and Claims Management.

Product modeling

The Salesforce Industries package extends the Product object to represent a wide variety of Insurance products and services. A range of prebuilt services (available as part of the managed package) uses the Products and Rating procedures you’ve defined and performs many tasks without any need for custom code. It’s worth reiterating that you can build complex product structures and rating algorithms with only builder tools.

How does product modeling work?

Product modeling involves creating a product specification with details required for a Quote (and eventually an Insurance Policy, which is a bound Quote). A typical product model has a Root product with multiple child products called Child Specifications (Specs). These Child Specs define the coverage that a policy provides as well as the items or people that the policy insures. The Root product could be auto insurance, home insurance, or a small business insurance plan, and the corresponding Child Specs could be coverages like Liability, Auto Driver, Bodily Injury and Property Damage, Contents, Critical Illness, and so on.

Attributes are the building blocks that capture features and characteristics. They can be assigned to both the Root product and the Specs. A Spec is essentially a collection of Attributes. This feature is the secret sauce behind the ability to design any product structure without extending the data model. Attributes differentiate one Spec from another.

There are four types of Child Specs:

• Insured Item Spec — For items that your products cover
• Insured Party Specs — For people that your products cover
• Coverage Specs — Benefits and coverages that your products provide
• Rating Fact Specs — Other data for pricing and rating, such as group information or past claim data

You can have more than one Child Spec of the same type; for example, in auto insurance, you can have multiple coverage Specs that represent liability coverage, collision coverage, and comprehensive coverage.

Both the Root product and the Child Specs use the Salesforce Product2 object. Here’s a snapshot of the standard object model used to create Root Product and Child Specs.

You will have a different combination of Child Specs added to your Root Product depending on the Insurance Line of Business (LOB) you are catering for. Typically coverage Specs apply to all LOBs, but the other Specs may not. You can also make a coverage required or optional, and they can also be associated with Insured Items and Insured Parties. You can also reuse the Child Specs across multiple Root products within one organization. The Spec can have different properties in each case by simply overriding the associated attribute data.

The following is an example of how the types of Specs might differ between LOBs:

Attributes — the secret sauce

Attributes enable you to extend the base Product2 object to model any complex product structure. Attributes are the building blocks used to define a Root Product and Child Specs. They are built to be reusable; that is, the same attribute can be assigned to more than one Spec or Root Product. When you assign Attributes, you can define additional properties or characteristics to make them unique for the Spec or Root product.

Let’s look at an example of a common property of insurance products called Deductible (also known as Excess in some countries). You want to apply the Deductible attribute to both Root Product and Child Specs but with different values. Instead of creating multiple deductibles, you would create one Deductible attribute and add it to different Child Specs but with different configurations.

For example, if you have two Specs — Coverage Spec 1 and Coverage Spec 2 — you can assign a value of $50 to the Deductible attribute set to Spec1 and $100 to the Deductible attribute assigned to Spec2. This information is then fed to the rating calculation.

Rating — unleash the actuaries

A rating is an algorithm calculates the Policy premium based on a set of input characteristics. The goal of the rating calculation is to evaluate the risks associated with the insurer to produce a premium value to cover those risks. Because these algorithms are usually moderate to high in complexity, they typically require lots of custom code, which in turn adds to maintenance issues. Thankfully, the Industries solution combined with OmniStudio provides a set of data tools that make creating rating rules a walk in the park.

• Calculation Matrices represent data in a tabular format to support looking up input, finding a matching row, and returning output.

Rating Procedure can be either a Calculation Procedure or an Integration Procedure

• Calculation Procedures contain a series of Calculation Steps executed in order. They consist of
• Variables and constants to be used in the calculation step
• Matrix Lookup to find information in the Calculation matrices
• Calculations (formula) to calculate the premium output values
• Integration Procedures are declarative, server-side processes that execute multiple actions in a single server call.

Let’s look at a typical process to implement Rating to understand how these tools are used:

1. Plan and prepare rating information. This involves creating and formatting rating data in spreadsheets.
2. Import the formatted rating information into Calculation Matrices using the Upload CSV function.

3. Define the Calculation Procedure and if needed (for complex implementation) create an Integration Procedure. This comprises the Rating Procedure.

4. Finally link the Root Product(s) to the Rating Procedure by specifying the Procedure name as the Rating Procedure Name.

Once you’ve set this configuration, the product (when selected by the user) will be rated as per the rules in the calculation matrices and rating procedure to calculate the total premium, and individual coverage cost, and any tax/surcharge related to the cost.

This setup and configuration reduces the time needed to create a complex rating implementation. Further, the implementation can be managed and maintained by a (trained) business user without any support from IT.

Conclusion

And that’s a wrap. To recap, we took a closer look at the different components of Salesforce Industries that help accelerate the delivery of value in the insurance industry. Now that you’ve taken a brief look at a typical industry implementation, you can see how OmniStudio helps reduce go to market by providing data and process tools to create complex quote and policy management processes.

The next post in this series will cover how all the elements come together to generate quotes, manage policies, and handle claims.