Prepare Your Insurance Data Model: Product / Offering
This is Part 3 of the Prepare Your Insurance Data Model series. It explains how a carrier defines what it can sell, service, and support before any customer has a policy, and why these reusable product definitions come first in the model. If you're new to the series, start with Part 1: Overview for the full map. If you've just read Part 2: People, this part shows what participants are actually buying into.
Objective
This article explains how carriers define what they can sell, service, and support before any customer-specific policy exists. It is written for product owners and implementation teams who need to set up the reusable product catalog that every policy will reference. The decisions here determine how policies are issued in Part 4.
The Product / Offering
The Product / Offering concept answers the question: what can the carrier sell, service, or support before any customer-specific policy exists? In the Building Blocks visual, Product / Offering sits before Policy because it represents the reusable definition of what the carrier offers. A policy is the sold or issued instance of that offering for a specific customer.
Figure 3. Product / Offering Focus in the Insurance Data Model
Figure 3 shifts the same visual to Product / Offering: what can be sold or serviced, before a policy exists.
What the Product / Offering Concept Represents
Product / Offering is the reusable definition of what the carrier brings to market. It should not be confused with the policy record. The product defines the available offering; the policy represents what a specific customer actually holds.
- A Personal Auto product defines the type of policy that can be issued, the coverage families that may apply, and the servicing context that agents should expect.
- A Commercial Property product defines the type of business coverage being offered and the policy structures that may be used for commercial customers.
- A Group Life product defines the employer-sponsored offering before individual employees, dependents, beneficiaries, and participant relationships are attached.
| Concept | Meaning | Example |
|---|---|---|
| Product / Offering | Reusable product definition or catalog-level construct | Personal Auto, Commercial Property, Group Life, Individual Life |
| Policy | Sold or issued instance for a specific customer | Policy number issued to a named insured or employer group |
| Coverage | Protection available or carried under the policy | Liability, collision, dwelling, life benefit, business interruption |
| Service context | How the offering should be serviced | Endorsements, certificate requests, beneficiary changes, coverage updates |
Product Foundation Tables
For insurance, Product / Offering builds on the platform product model hierarchy and the insurance-specific product model classes available through installed applications. Validate the exact tables in the target instance because available product model classes can vary by release and installed plugins.
| Product / offering area | Table examples | How to use it |
|---|---|---|
| Base product model | cmdb_model | Represents product models that a company sells and supports. |
| Service product model | cmdb_service_product_model | Use when the product model is represented as a service model. |
| Personal lines insurance product model | sn_ent_b2c_ins_policy_model | Use for personal lines offerings such as auto, homeowners, renters, or umbrella where installed. |
| Commercial lines insurance product model | sn_ent_b2b_ins_policy_model | Use for commercial offerings such as commercial property, general liability, commercial auto, or BOP where installed. |
| Group life insurance product model | sn_ent_group_life_ins_policy_model | Use for employer-sponsored group life offerings where installed. |
| Individual life insurance product model | sn_ent_indiv_life_ins_policy_model | Use for individual life offerings where installed. |
Product / Offering Decisions Before Moving to Policy
Before configuring policy records, implementation teams should confirm how product definitions will be represented, reused, and connected to service patterns.
| Decision | Why it matters |
|---|---|
| Which products or offerings are in scope for the implementation? | Determines which product model records or classes need to be created or loaded. |
| Are Personal Lines, Commercial Lines, Individual Life, and Group Life handled differently? | Determines whether separate product model classes, policy classes, service definitions, roles, or access patterns are needed. |
| Which coverages are available for each offering? | Connects Product / Offering to the Coverage section and prevents coverage options from being buried only inside policy records. |
| Which work types are supported for each offering? | Helps determine service definitions, case types, playbooks, and task templates later. |
| Which product data remains mastered outside FSO? | Identifies where remote table, lookup-save, integration, or reference-only patterns may be needed. |
Key Takeaways
- Product / Offering defines what can be sold or serviced; Policy represents what a specific customer actually holds.
- Product / Offering should be kept separate from Policy so the implementation can scale across lines of business and servicing patterns.
- Coverage options and service patterns should be considered at the product level before policy-level configuration begins.
- Implementation teams should validate installed product model tables and plugins in the target instance before committing to a table structure.
Product / Offering defines what the carrier can sell. Policy is the instance actually issued to a customer.
What's Next
Continue with Part 4: Policy to see how an issued policy ties a customer to a product. For the underlying product model tables, see the FSO Core Insurance Tables reference.
Related reading:
- Getting Started with Insurance Servicing in FSO
- FSO Learning and Enablement Resources
- Part 3: Product / Offering
- Part 4: Policy | Coverage | Risk
- Part 5: Case Management: Service Definitions, Case Types, Case Tables and Application Scoping
Get involved:
- Subscribe for updates on the FSO Community Forum
Happy implementing. Comment below for questions, additional assets, or to share your Insurance Servicing data model success stories.
Note: Table names should be validated against the target release, installed plugins, and implementation scope before configuration.
