Prepare Your Insurance Data Model: Work
Objective
This article is part of the Prepare Your Insurance Data Model series. It covers the Work that services a customer’s policy: Service Definitions, Case Types, the tables behind them, and how the insurance servicing applications are scoped. It explains how FSO separates what a customer requests from how the carrier fulfills it, and how a request becomes cases, tasks, and resolved activity. It is written for implementers, solution consultants, and partners designing servicing. If you’re new to the series, start with Part 1: Overview for the full map of the building blocks. If you already know the model, go straight to the decisions your service and case design needs to answer.
The Work
Work represents servicing and operational activities performed for customers, policies, coverages, risks, and authorized participants. Unlike People, Product / Offering, Policy, Coverage, and Risk, Work is not primarily a static data entity. It is the operating layer that turns customer needs into routed, tracked, and resolved activity.
In FSO, Work should be explained through Service Definitions, Case Types, table inheritance, and work orchestration capabilities. The goal is to separate what service is being requested from how the organization processes and fulfills that request.
Figure 7. The Work in the Insurance Data Model
Figure 7 highlights Work: Service Definitions and Case Types, operationalized through cases, tasks, messaging, SLAs, and work orders.
What Is a Service Definition?
A Service Definition represents a specific service that a carrier offers to customers, producers, and other authorized participants. It answers the question: what is the customer trying to accomplish? In ServiceNow Customer Service Case Types, Service Definition records store details about services provided to customers and can be associated with products, catalog items, and case types.
- Service Definitions are requestable and repeatable.
- They should be understandable to customers, producers, agents, and service teams.
- They are often product-aware or policy-aware.
- They can have their own intake experience, business rules, routing, SLA expectations, and fulfillment pattern.
Rule of thumb
If an authorized participant can explicitly request it and the request can be independently tracked to closure, it is a strong candidate for a Service Definition.
| Service Definition category | Examples | Typical FSO intent |
|---|---|---|
| Policy Information | Policy Copy Request; ID Card Request; Evidence of Insurance; Renewal Assistance | Provide information or documents related to an existing policy. |
| Customer / Party Changes | Address Change; Named Insured Change; Authorized Representative Update; Beneficiary Change | Change customer, party, or authority-related details connected to policy servicing. |
| Policy Administration | Cancellation; Reinstatement; Endorsement Request; Renewal Support | Manage administrative changes to an existing policy. |
| Coverage Administration | Add Coverage; Remove Coverage; Limit Change; Deductible Change | Change coverage details or policy protection choices. |
| Documents & Billing | Certificate of Insurance; Billing Inquiry; Payment Plan Change; Refund Request | Fulfill document, certificate, billing, and payment-related servicing requests. |
| Claim Servicing Requests | Raise Claim; Update Claim Information; Submit Claim Document; Check Claim Status | Represent requestable actions tied to claim records without modeling the full claims lifecycle here. |
What Is a Case Type?
A Case Type is the operational container used to process, route, track, and resolve work. It answers the question: how will the organization fulfill the request? ServiceNow defines a Case Type as the processes and data needed to resolve a specific type of customer issue. In FSO, a new case type that cannot extend an existing application case type should extend FSO Base Case [sn_bom_case].
- Case Types define process and lifecycle.
- They define data requirements and user experience for a category of work.
- They influence routing, assignment, fulfillment, escalation, and resolution.
- They should be created when the work requires a materially different operating model.
| Case Type | Purpose | Example Service Definitions that may route to it |
|---|---|---|
| Policy Servicing | Standard servicing requests for an existing policy. | Policy Copy Request; Address Change; Coverage Change; Certificate of Insurance; Payment Plan Change; Raise Claim; Check Claim Status |
| Complaint Management | Customer concerns and issue resolution. | Complaint intake; service dissatisfaction; unresolved servicing issue |
| Regulatory Inquiry | Formal inquiries and compliance-driven responses. | Regulatory request; compliance inquiry; formal response request |
| Special Handling | Complex servicing, exception review, or escalated work. | Complex endorsement; exception processing; escalated coverage or billing issue |
How Do Service Definitions and Case Types Relate?
Service Definitions and Case Types should not be treated as interchangeable. A Service Definition describes the specific service being requested. A Case Type describes the operational model used to fulfill that service. The relationship is often many-to-one: multiple Service Definitions can route into the same Case Type when they share a common lifecycle, fulfillment team, security model, and resolution pattern.
| Modeling question | Use Service Definition when... | Use Case Type when... |
|---|---|---|
| What is changing? | The request changes, but the fulfillment pattern is generally the same. | The process, lifecycle, data, team, or security model changes. |
| Who asks for it? | Customers, producers, agents, or authorized participants can request it explicitly. | The organization needs a distinct operational container to manage the work. |
| Example | Policy Copy Request, Address Change, Beneficiary Change, Claim Status Request. | Policy Servicing, Complaint Management, Regulatory Inquiry, Special Handling. |
| Design risk | Too few Service Definitions can make intake generic and hard to route. | Too many Case Types can fragment operations and reporting. |
Recommended modeling pattern
Model the customer-facing request as a Service Definition. Route it to the Case Type that best represents the processing model. Keep claims lifecycle work out of this servicing article, but include claim-related servicing requests when they are requestable and trackable.
Decision Framework Before Configuration
| Decision | Why it matters |
|---|---|
| Is this something a customer, producer, or authorized participant explicitly requests? | If yes, start by considering a Service Definition. |
| Does the request share the same lifecycle, routing, and fulfillment model as other servicing requests? | If yes, route it to an existing Case Type such as Policy Servicing. |
| Does the work require a materially different process, data model, team, lifecycle, or security model? | If yes, consider a separate Case Type. |
| Is the work part of a claim lifecycle rather than an independent request? | If yes, model it in the claims operating model rather than as a servicing Service Definition. |
| Does the work need tasks, child cases, messages, SLAs, assignments, documents, or work orders? | If yes, define the orchestration layer early so fulfillment and reporting remain consistent. |
Key Takeaways
- Service Definitions model what services the carrier offers.
- Case Types model how those services are processed and fulfilled.
- Multiple Service Definitions can route to the same Case Type when they share process, data, routing, and lifecycle.
- FSO operationalizes the relationship through cases, tasks, messages, SLAs, assignments, escalations, documents, and work orders.
Case Tables and Application Scoping
This section covers the tables behind the Service Definitions and Case Types described above, how the case table hierarchy is layered, and how the insurance servicing applications are scoped.
Actual FSO and CSM Tables to Know
The following tables are the implementation anchors that come up most often when configuring the Work section, connecting each concept to actual table names.
| Concept | Table name | Purpose / how to use it |
|---|---|---|
| Case Type | sn_case_type | Stores defined case types. Use this as the configuration anchor for operational containers such as Policy Servicing, Complaint Management, Regulatory Inquiry, or Special Handling. |
| Service Definition | sn_case_type_selection | Stores defined service definitions. Use this as the configuration anchor for requestable services such as policy copy, address change, coverage change, COI, and claim servicing requests. |
| Service Definition Category | sn_csm_case_types_service_category | Stores service definition categories. |
| Service Definition Category Relationship | sn_csm_case_types_service_category_rel | Stores relationships between service definitions and service definition categories. |
| Product Service Relationship | sn_csm_case_types_product_service_rel | Links products to service definitions for product-aware service availability. |
| Service to Service Relationship | sn_csm_case_types_service_to_service_rel | Stores relationships between service definitions, such as parent-child or related services. |
| Catalog Service Relationship | sn_csm_case_types_catalog_service_rel | Links catalog items or record producers to service definitions for portal intake. |
| Service Definition User Criteria | sn_csm_case_types_service_user_criteria | Controls which service definitions are available to agents and internal users. |
| Service Definition Customer Criteria | sn_csm_case_types_service_customer_criteria | Controls which service definitions are available to customers. |
Insurance Servicing Case Table Hierarchy
Insurance servicing cases should also be explained as a layered table hierarchy. This avoids presenting Policy Servicing as only a generic CSM case and shows how FSO adds domain behavior on top of the platform case foundation.
| Layer | Table name | What this layer contributes |
|---|---|---|
| Platform work base | task | Base work table with task-level behavior such as assignment, state, priority, activity, and SLA integration. |
| CSM Case | sn_customerservice_case | Customer Service Management case table and base case foundation. |
| FSO Base Case | sn_bom_case | Financial Services Operations base case layer. Extend this when a new FSO case type cannot be extended from an existing application case type. |
| Insurance Policy Base Case | sn_ins_policy_b2c_base or LOB equivalent | Insurance servicing layer for policy service cases. Validate exact base by installed insurance servicing app and line of business. |
| Application Service Case | Example: sn_ins_indiv_life_case | LOB-specific service case layer that adds application-specific logic, fields, views, playbooks, and workflows. Validate exact table in the installed app. |
Insurance Servicing Application Scoping
Installed Insurance Servicing applications determine the available servicing case tables, service definitions, record producers, flows, playbooks, workspaces, and roles. Use the app IDs below as scoping cues for implementation validation.
| Servicing area | Application / app ID | What to validate in the target instance |
|---|---|---|
| Personal Lines Servicing | sn_ins_policy_b2c | Personal auto, homeowner, condo, renter, and umbrella policy servicing tables, service definitions, roles, and record producers. |
| Commercial Lines Servicing | sn_ins_policy_b2b | Commercial property, commercial auto, general liability, umbrella, farm/ranch, and BOP servicing constructs. |
| Individual Life Servicing | sn_ins_indiv_life | Individual life and disability servicing case tables and service definitions. Example application service case: sn_ins_indiv_life_case. |
| Group Life Servicing | sn_ins_group_life | Group life and group disability servicing constructs, including employer / member servicing use cases. |
How Does FSO Operationalize Work?
Once a Service Definition is associated with the appropriate Case Type, FSO operationalizes the request through case records, tasks, child cases, messaging, SLAs, assignments, escalations, documents, and, where needed, work orders. These supporting objects turn a business request into executable work.
| Work concept | Primary table(s) | Related tables / notes |
|---|---|---|
| Service Definition | sn_case_type_selection | Categories: sn_csm_case_types_service_category Category relationships: sn_csm_case_types_service_category_rel. |
| Service-to-product availability | sn_csm_case_types_product_service_rel | Determines which services are available for a product or policy context. |
| Service-to-catalog intake | sn_csm_case_types_catalog_service_rel | Connects service definitions to record producers or catalog items. |
| Service visibility | sn_csm_case_types_service_user_criteria sn_csm_case_types_service_customer_criteria |
Filters service availability for agents and customers. |
| Case Type | sn_case_type | Case type configuration record. The selected target table must extend sn_customerservice_case. |
| Policy Servicing Case | sn_bom_case > insurance policy base case > LOB case table | Use the installed app’s policy service case table. Examples vary by LOB and release. |
| Case Task | sn_customerservice_task | Use for assignable activities related to a case. |
| Documents / Attachments | sys_attachment | Stores supporting documents attached to servicing work. |
| Assignment groups | sys_user_group sys_user_grmember |
Supports group routing, queues, and membership. |
| SLA definitions | sla_definition and SLA records | Supports response and resolution commitments. |
| Work Orders | sn_work_order, where applicable | Use when servicing work requires field, vendor, inspection, or repair execution. |
What’s Next
Related articles:
Reference documentation:
Get Involved:
Comment below with questions, or share how your insurance data model is coming together.
