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

Designer (32).png

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.

Note: Table names should be validated against the target release, installed plugins, and implementation scope before configuration.

What’s Next

Related articles :

Reference documentation :

Get Involved :

FSO Community Forum

Comment below with questions, or share how your insurance data model is coming together.

News Jace Pro NJP

Prepare Your Insurance Data Model Part 5: Case Management