Skip to main content
Build the future with Agentforce at TDX in San Francisco or on Salesforce+ on March 5–6. Register now.

Dive into Product Modeling

Learning Objectives

After completing this unit, you’ll be able to:

  • Describe product modeling objects and how they work together.
  • Explain how product modeling objects work with rating processes.
  • List the types of rules you can use in product modeling.

About Product Modeling

Before an insurance company sells a plan to a customer, the company captures many details about the person or object they’re insuring. Before Anna gets her car insurance, Cumulus must find out what car she drives, the age of the vehicle, her license details, and that’s just to start. 

For Anna's health insurance plan, Cumulus needs to determine her age, if she smokes, her medical history, and more. Quote, Rate, and Apply captures this information in product modeling, one of the three key aspects of quoting. A lot happens behind the scenes when consultants, admins, and developers plan and model a product. Let’s dive deeper. 

Product Modeling Building Blocks

You create product models using four basic building blocks: root products, child specifications, attributes, and rules. 

Relationship between root product, child specifications, attributes, and rules

Root Product

Root product is the plan or product that the insurance company offers. 

Product icon

It’s the container for all the other parts of the model, and you can only have one root product for each policy. The root product can be renters insurance, small or large group health insurance, small business insurance… really, any insurance plan you can imagine. The Digital Insurance Platform has a flexible product specification model and supports a wide range of products. This is great because you don’t need to extend the data model to create additional objects. 

Child Specification

A child specification, also called a child spec, defines who and what are insured and the benefits and coverages that the plan provides. This diagram shows different types of child specs, like insured party, insured item, and different coverages. 

Relationship between root product and child specs

The table lists the child spec types and what they do.

Child Spec Type
Purpose

Insured Item Spec

Defines what is covered by the insurance product. For example, when Anna is insuring her car, all the details (attributes) about her car go into Insured Item Specs. 

Insured Party Spec

Defines who is covered by the insurance product. Anna’s personal information like her age, gender, and medical history go into the Insured Party Spec.

Coverage Spec

Defines the benefits and coverages the insurance product provides. Liability coverage in Anna’s car insurance policy and various benefits in her health insurance plan are examples of Coverage Specs.

Rating Fact Spec

Defines other data for pricing/rating, such as group information or past claim data. 

You can reuse specs on multiple products.

Attribute

An attribute defines product specifications. This diagram shows the relationship between attributes and products. Notice that you can define attributes for both root products and child specs.

Relationship between child specs and attributes

Remember how Cumulus needs to capture information about Anna, like what car she drives, how old her car is, and Anna’s age? Well, all these details are stored as attributes. Attributes are assigned to a product, whether the product is a child spec or a root product. The Salesforce attribute model provides an inherent advantage in that you don’t need to add new fields to the data model for every piece of data you want to collect about the policy, items or customers. 

Rule

Rules define how an insurance product behaves. You can define rules for root products and child specs. This diagram shows the relationship between rules and product. 

Relationship between child specs and rules

The Digital Insurance Platform gives you a variety of rules to configure. Some examples include product eligibility rules, underwriting rules, attribute and attribute value rules, and optional coverage rules. The table describes each type of rule.

Rule Type
Purpose
Example

Product eligibility 

This type of rule is an expression that evaluates if the requirements are true or false. During the quoting process, users only see the products for which they’re eligible. 

Use it to capture requirements for an applicant to determine their eligibility for a policy, namely a particular root product. 

Screen out anyone under the age of 65 for a Medicare supplement insurance product. 

Screen out anyone who’s not a student for a Student Driver product.

Underwriting

The evaluation of an underwriting rule as true triggers the specified state change. You can also set an action to run, such as creating a task for an underwriter to review the quote.

Use an underwriting rule to move a quote or policy to a user-defined state, such as Underwriting or Declined. 

These rules work with state models. State models define states and state transitions for objects. States for quotes can be Submitted, Approved, or Underwriting. You also define state transitions, like Submitted to Approved, or Submitted to Underwriting. 

Send quotes to underwriting if an operator’s licensing points are greater than five.

Send quotes to underwriting when a driver has more than four points on their driving record. 

Attribute

An attribute rule captures dependencies between attributes. If an attribute expression is true, you can hide an attribute or some of its values, display messages, or set values for an attribute. In this way, you control one attribute based on other attributes.

Set the limit for debris removal to 5% of the total property limit.

Hide deductible for liability coverage when the limit is less than $50,000.

Optional coverage

An optional coverage rule controls the configuration options for optional coverages. Types of optional coverage rules include: coverage eligibility, required coverage, default selected coverage, coverage validation, and coverage relationships.

The Employee Auto Liability coverage is available only when the optional Rental Car Reimbursement coverage is selected.

The Liquor Liability coverage is available for selection only when the business type is restaurant or bar.

Putting It All Together

Justus and his project team need to determine the optimal number of products to create when they map out requirements. Some insurance companies opt to create very few products and make the attributes highly configurable. Others create a larger number of products with static attributes to reduce configurable steps. Generally, you should combine product offerings with similar structures and rating algorithms into a single configurable product definition.

Time to Brush Up

The following flashcards show you examples of root products, child specs, and attributes. 

Read the question or term on each card, and then click the card to reveal the answer. Click the forward arrow to move to the next card and the back arrow to return to the previous card.

Product Modeling and Rating

Once you define your root product and assign all the child specs and attributes, it’s time to make sure you can use the root product to calculate quotes and perform rating. With Quote, Rate, and Apply, you define product models and rating procedures separately. This way, you can reuse the rating procedures instead of creating new ones for each new product. Because they’re defined separately, you must specify in the root product which rating procedure you want to use. 

The two types of rating procedures are expression sets and OmniStudio Integration Procedures. Use expression sets for simpler rating situations. For more complex rating scenarios, such as those with multi-auto or composite health ratings, use multiple expression sets together in an Integration Procedure. 

Once you’ve specified the type of rating procedure your root product should use, the next step is to map attributes from the product model to the rating procedure. This diagram shows a relationship between root products and rating procedures. 

Relationship between root products and rating procedures

As the diagram shows, you can link multiple root products to a single rating procedure. 

Rating procedures are complex formulas that calculate quotes. The formulas require variables, also called inputs. Make sure the inputs match the corresponding attributes in the product model. Once you add inputs, Quote, Rate, and Apply connects the rating procedure and product models and makes all the necessary calculations to produce a quote. 

Share your Trailhead feedback over on Salesforce Help.

We'd love to hear about your experience with Trailhead - you can now access the new feedback form anytime from the Salesforce Help site.

Learn More Continue to Share Feedback