Explore the Product Model
Learning Objectives
After completing this unit, you’ll be able to:
- Describe root products.
- Summarize the different types of child specs for root products.
- Explain the build sequence.
Before You Start
Before you start this module, consider completing the following recommended content.
The Product Model
An insurance product is a financial contract in which the provider guarantees to pay for covered claims. In return, the buyer agrees to pay a monthly premium. A product model is a structured definition of what an insurance company sells and services. The model serves as the blueprint for services and applications in Salesforce to create a configured instance of a product, which is called a policy.
The model structures all the elements that constitute the insurance product definition in a way that can be easily configured and administered. Essentially, the model translates a business definition into technology.
Product modeling is an art and a science. When you design a product model, you must consider many details, especially those that affect the price and options the end user chooses during the quoting process. It’s essential to get the product model correct because the Digital Insurance Platform services use it as a blueprint to create quotes, policies, and much more.
Just as a data model is at the heart of most enterprise applications, product models and rating algorithms are at the heart of Salesforce insurance functionality. The product model is designed to change based on rating or coverage, but it’s largely independent of any specific user interface design or business process.
You create product models using four basic building blocks: root products, child specifications, attributes, and rules. The main product you model is the root product, which is the root product specification. Here’s the general structure for a root product and other specifications (specs) supporting it.
In Salesforce, the root product and child specs are all product records but have different record types. Add child specs, such as coverage specs, to the root product. Attributes added to the products represent the features and characteristics that define and differentiate specs. Rules define how an insurance product functions. You can define rules for root products and child specs.
Attributes and child specs are reusable. For example, many coverages sometimes use the same attribute named Deductible. Multiple medical plans can contain the same Primary Care Visit coverage spec. After adding these components to a particular spec, you can further configure them.
Types of Child Specs
A child spec defines who and what is insured and the benefits and coverages the plan provides. As you plan your product model, decide which types of child specs you need. This table summarizes the differences among the child specs.
Spec |
Purpose |
Is Spec Stored as Line Item? |
Is Spec Carried Through to the Policy? |
|---|---|---|---|
Insured Item |
Define an insured item |
Yes |
Yes |
Insured Party |
Define an insured person |
Yes |
Yes |
Rating Fact |
Support the rating calculation |
No |
No |
Coverage |
Define benefits |
Yes |
Yes |
Here are some examples of child specs and when to use each one.
-
Insured Item Spec: Use this spec to define insured entities such as a business, a vehicle, or a boat.
-
Insured Party Spec: Use this spec to define insured people, such as a boat operator or a person receiving individual medical insurance. Note that you don’t define members for group insurance as individual insured parties.
-
Rating Fact Spec: Use this spec to define information referenced and pulled during rating. These specs differ from the other child specs because they don’t carry through directly to quote line items or the policy. For example, a rating fact can have attributes to capture claim history just to use in a rating calculation. You also use this spec to define group insurance census data headers.
-
Coverage Spec: Use this spec to define insurance benefits such as emergency room visits or collision coverage.
The Build Sequence
Cumulus Insurance is a large, well-diversified provider of insurance services nationwide. It offers a variety of insurance plans, including auto, business, and homeowners coverage. Cumulus is currently seeking to adopt the Digital Insurance Platform to transform its legacy quoting system.
Enter Justus Pardo, a highly skilled solution architect and product modeling expert.
Over the next units, follow Justus as he models and implements products for Cumulus. Justus follows a consistent process for approaching a product modeling project.
Stage |
Description |
|---|---|
Analyze |
Closely analyze all the product information—product guide, rating manuals, and other specifications. The modeler must be able to explain the product and associated rating to the broader team in business terms. |
Define |
Define specs, attributes, and rules. Typically, work top-down during the definition stage, first defining the root product, then identifying the child specs and their relationships. Next, define the attributes and associate them with the appropriate specs. Finally, define the rules. |
Build |
Implement the product model in Salesforce. |
Test & Iterate |
Test the prototype and refine the model based on user experience and feedback. Continually iterate and make steady improvements. Use your discoveries to apply to future product models and projects. |
This module focuses primarily on the Build stage of the overall process. While the Define stage proceeds from top to bottom—root product, specs, attributes—the Build stage is the opposite.
First, Justus creates all the attributes. Next, he creates the child specs and further defines the attributes after adding them to the specs. Finally, he creates the root product, adds the specs to the root products, and defines any rules. You learn more about these steps in the following units.
In this unit, you learned about the product model building blocks and the build sequence. In the next unit, you learn how to create the attributes.