Design Claims Management Products
Learning Objectives
After completing this unit, you’ll be able to:
- Design a claim product model that supports consistent intake and downstream management.
- Build a reusable claim structure with a root claim, and repeatable damage and injury components.
- Standardize claim data capture by applying classifications and attributes.
- Connect policy terms to claim behavior using product attribute scopes and mapped scopes.
- Configure claim context and workflow rules so the model is executable at run time.
Ground Claims in Product Design
If you completed the Product Administration for Digital Insurance badge, you learned that product models define what an insurer sells and under what terms. That blueprint drives quoting and policy servicing.
Claims require the same design discipline at a different moment. When a loss occurs, it’s important for the platform to answer key questions: What kind of claim is this? Which items or injuries are involved? Which limits, deductibles, and out-of-pocket terms apply?
If a claim isn’t modeled well, teams fall back on improvisation. Intake captures inconsistent details, adjusters calculate limits and deductibles manually, and processes diverge across handlers.
Claims Management for Digital Insurance solves this challenge by reusing the same modeling foundations across Digital Insurance. The difference is what you model. Instead of a sellable policy, you design the claim record and how it behaves during claim intake and financial management.
In this unit, you examine the core building blocks of a claims model and explore how a product administrator designs a claim that supports both customer experience and operational control.
Explore the Building Blocks
A claim product model uses building blocks that keep the claim structured and executable. Here’s a quick overview of the key components and the role they play in the Claims data model.
-
Catalogs and Categories organize and publish claim products by line of business, so experiences and run-time functions reference the correct model.
-
Classifications act as reusable templates for root claims, damage specs, and injury specs. Attributes assigned to a classification are inherited by every product within that classification.
-
Claim Attributes capture the information intake reps and handlers record, such as damage description, repair estimate, and treatment details. Extended attributes pull values from related records to reduce duplicate entry.
-
Products and Structure define the root claim product and its child components, such as damage and injury specs, assembled into a hierarchy through product groups.
-
Product Attribute Scopes map policy terms such as deductibles, limits, and copay to enforceable behavior during claim financial management. Scopes define whether each term is tracked at the policy, policy coverage, claim, or claim coverage level.
-
Claim Context informs the platform which claim product model governs execution and how the product hierarchy maps to claim entities.
-
Stages and Rules govern claim progression and automation. Stage definitions establish allowed transitions, while workflow rules apply criteria and trigger actions at each transition.
These configuration elements work together to define claim structure, connect products to policy terms, and manage run-time behavior. To explore how they come together, follow a product administrator through a full configuration.
Build a Claim Product
Justus Pardo is a product administrator at Cumulus Insurance. He’s setting up an auto claim product model that reflects two common realities: a single loss event can involve multiple damaged assets and include both injuries and property damage.
Rather than creating a flat claim record with many custom fields, Justus models the claim in line with standard behavior: a root claim record with repeatable damage and injury components. This structure enables run-time functions to create, extend, and process the claim consistently as new details are added during intake.
Define Classifications and Attributes
Justus first creates three product classifications that represent the repeating structure of an auto loss: Auto Claim Root, Damaged Property, and Involved Injury. These classifications act as templates, standardizing claim structure and data definitions before any products are created.
Next, Justus defines attribute definitions and assigns them to the relevant classifications. The Damaged Property classification receives attributes such as damage description, damage location, and severity, along with identifying details such as make, model, and year.
Similarly, the Involved Injury classification receives attributes such as injury type, affected area, and treatment details.
Assigning attributes at the classification level ensures every product based on that classification inherits attributes automatically. As Cumulus adds claim products for motorcycle, RV, or watercraft lines, those products can reuse the Damaged Property classification without separate configuration. If a specific product needs variation, you can still override attributes at the product level.
Assemble the Claim Product Structure
With classifications and attributes in place, Justus creates an Auto Claim Root product based on the Auto Claim Root classification.
On the product’s Structure tab, Justus assembles the claim hierarchy. He creates a Damaged Property Group and an Injury Group, then adds the Damaged Property classification under the first group and the Involved Injury classification under the second group.
This structure makes repeatable claim components possible. One claim can contain multiple damaged items and multiple injuries without redesign as intake becomes more complex.
To make the model available for use, Justus adds the Auto Claim Root product to the Insurance Claims catalog under the Auto Insurance Claims category. The catalog is how experiences and run-time processes reference the relevant claim product for a given line of business.
Map Policy Terms
So far, the model describes what a claim looks like. Attribute scopes define how the claim connects to enforceable policy terms.
Justus creates product attribute scope records for deductibles, limits, and other financial terms, then maps each to the corresponding attribute on the root policy product. These scopes define how policy terms are tracked and enforced when claims reference the issued policy. Although the claim product defines the structure of the claim itself, the financial terms that govern claim payments are configured on the root policy product.
For example, the Auto Silver product in this scenario includes a deductible applied per claim, another that accumulates across the policy term, an out-of-pocket maximum at the policy level, and a coverage limit validated when claim payments are issued.
Each scope record specifies the level at which the term aggregates: policy, policy coverage, claim, or claim coverage.
This mapping makes financial terms trackable and consistently applied at run time instead of leaving them open to interpretation. Later in this badge, you learn how Digital Insurance uses these scopes to apply deductions, enforce limits, and prevent overpayment.
Register Claim Context
Claim context tells Digital Insurance which claim product model governs execution and how the product hierarchy maps to claim entities.
Justus creates a claim context record that points to the Auto Claim Root product as the governing model. The context maps each level of the hierarchy, root claim, damage spec, and injury spec, to the corresponding claim entities that intake flows create at run time.
This mapping is required only when multiple claim contexts exist for different lines of business. If no mapping is configured, run-time APIs fall back to a default Claim Context. Either way, guided intake and claim operations create and update the correct hierarchy as details change.
Manage Claim Workflow
Justus finishes the model by defining stages and configuring claim workflow rules on the root claim product. These tasks work together, but they serve distinct purposes.
Stage Management defines the lifecycle structure for all claims. It establishes the stages and which transitions are allowed. For example, a claim can move from Open to Under Investigation, but not directly from Open to Closed. These stage definitions apply across the Claim object as a whole.
Claim workflow rules apply at the root product level. They define the criteria and actions that execute when a stage transition occurs for a specific claim product. Stage Management manages the allowed transitions. Claim workflow rules determine what is true and what happens when a claim moves between stages.
In the auto claim model here, a workflow rule automatically opens Collision coverage when certain conditions are met and transitions the claim from Draft to Open. That transition can then trigger assignment or other automation.
This is where operational control becomes product aware. Stage definitions provide consistent lifecycle guardrails across all claims. Claim workflow rules add flexibility at the product level, helping auto, homeowners, or other claim types to enforce different requirements and trigger different actions. The rules are defined once on the root product and enforced consistently, regardless of channel or agent.
What’s Next?
The auto claim product model is complete.
In this unit, you discovered that classifications and attributes define what information belongs on a claim, damaged item, and injury. The product hierarchy describes how one claim can contain many items and injuries. Attribute scopes connect the model to policy terms so the platform can implement limits and deductibles during financial management. Claim context tells Digital Insurance how to build the correct claim structure at run time. Workflow rules help automate and govern claim progression.
In the next unit, you shift from design to run time. You follow a claim from the first phone call through a guided intake experience and learn how this product model creates a structured, governed claim record from the first conversation.