Prepare Your Insurance Data Model: People

This is Part 2 of the Prepare Your Insurance Data Model series. It explains who takes part in an insurance relationship, from policyholders and producers to carrier employees and vendors, and how FSO represents each of them. If you're new to the series, start with Part 1: Overviewfor the full map of the six building blocks. If you already know the model, go straight to the questions about people that your implementation needs to answer.

The People

The People concept is the right place to start because every insurance data foundation depends on understanding who participates in the insurance relationship, how each participant connects to the policy, and what each participant is allowed to do.

A policy may look like a contract between a carrier and a policyholder, but servicing rarely involves only those two parties. A single service or claims scenario may include a policyholder, household member, business contact, benefits administrator, producer, carrier employee, vendor, TPA, claims adjuster, beneficiary, or authorized representative.

Figure 2. The People in the Insurance Data Model

 

 

Figure 2 isolates the People concept from the building blocks figure in the Overview: the four people groups, how authority and work connect them to the policy, and the FSO configuration area each group maps to.

What the People Concept Represents

The People concept answers a simple question: who participates in the insurance relationship? At first glance, the answer appears to be the policyholder. In reality, insurance servicing and claims operations involve a broader ecosystem of participants.

• Policyholders own policies or receive coverage.
• Producers sell or service policies on behalf of the carrier.
• Carrier employees perform underwriting, servicing, claims, and supervisory work.
• Vendors and TPAs participate in specialized servicing or claims processes.

These groups are distinct because they participate in the insurance value chain differently. Keeping them distinct prevents customer ownership, producer authority, internal work responsibility, and external partner participation from being collapsed into one generic party model.

The Four Participant Groups

The first step is to separate the people and organizations that participate in insurance servicing. This creates the mental model before any table-level decisions are made.

Participant group	Who it represents	Configuration intent
Policyholders	Individuals, households, businesses, or employer groups that own the policy or receive coverage	Represent the customer context using Customer Data Foundation records.
Producers	Agents, brokers, MGAs, agencies, and producer staff that sell or service policies	Represent the distribution and service ecosystem without treating producers as policyholders.
Insurance Organization	Carrier employees who perform servicing, underwriting, claims, or supervisory work	Represent internal fulfillment through users, groups, roles, queues, and assignments.
Vendors / TPAs	External partners such as TPAs, adjusters, medical review vendors, repair networks, and inspection vendors	Represent bounded participation in service or claims work without granting broad customer authority.

People, Policy, Authority, and Work

The People concept does not stand alone. People connect to Policy through relationships and authority, and Work is performed against policy, coverage, risk, and people. This is the context the configuration needs to support.

Connection	Insurance meaning	What the configuration must support
People → Policy	A person or organization owns, represents, services, or supports a policy	Capture who is connected to the policy and why.
People → Authority & Work	A participant may act in a defined capacity, and may request, perform, approve, or support work	Distinguish named insured, beneficiary, and producer-of-record patterns, and support routing, visibility, and bounded access for servicing and claims.

How People Are Configured in FSO

The bottom strip in Figure 2 translates the People concept into FSO records. The goal is to separate who the person or organization is from what that party is allowed to do.

Visual bucket	FSO construct	Table examples	Purpose
Consumers	Consumer profile	• csm_consumer
• csm_consumer_user	Individual policyholders and portal-enabled consumer users.
Accounts	Business customer	customer_account	Businesses and employer groups that own or sponsor coverage.
Contacts	Business contact	customer_contact	People acting on behalf of a business account.
Households	Household and household membership	• csm_household
• csm_household_member	Related consumers in a shared household or family context.
SMF Service Organizations	Service organization and related members / locations	• sn_customer_service_organization

• sn_csm_service_organization_member

• sn_csm_business_location | Agencies, brokerages, MGAs, producer staff, service locations, TPAs, and partner organizations. |
| SMF Relationships | Relationship and responsibility records | • sn_customerservice_team_member

• sn_customer_rel_consumer_to_user

• sn_customer_rel_household_to_user

• sn_customer_rel_consumer_to_consumer

• sn_customer_rel_household_member_relationship | Defines customer-level access, delegation, and relationship context. |

Policyholders and Customer Records

Policyholders should be represented in Customer Data Foundation before policy or coverage data is configured. This provides the customer foundation for policy ownership, servicing access, and reporting.

Scenario	Use this record	Table name	Guidance
Individual policyholder	Consumer	csm_consumer	Use for Personal Lines and Individual Life customers.
Consumer with login access	Consumer User	csm_consumer_user	Use when the consumer needs portal access or user-linked interactions.
Business policyholder or employer group	Account	customer_account	Use for Commercial Lines customers and group sponsors.
Person acting for a business	Contact	customer_contact	Use for risk managers, CFOs, HR admins, benefits admins, and other account representatives.
Family or related individuals	Household / Household Member	• csm_household
• csm_household_member	Use when multiple consumers share household, family, billing, or policy context.

Contacts and Consumers

A real-world person can participate in more than one context. The same person may be a Contact for a business account and a Consumer for a personal policy. The data design should reflect the business context rather than forcing every person into one record type.

Situation	Recommended record pattern	Why it matters
Person owns a personal auto policy	Consumer [csm_consumer]	The person is the individual customer.
Same person manages insurance for a business	Contact [customer_contact] on Account [customer_account]	The person is acting on behalf of the business.
Same person belongs to a family household	Household Member [csm_household_member] linked to Household [csm_household]	The person participates in a shared household context.
Same person has authority on a life policy	Policy participant / authority pattern	The authority should be scoped to the policy or coverage context, not only the customer record.

The Service Ecosystem

The Producers, Insurance Organization, and Vendors / TPAs cards in Figure 2 represent different parts of the service ecosystem. They should not be collapsed into one generic organization pattern because each group participates differently.

People group	Use this construct	Table examples	Configuration guidance
Producers	Service Organization + Member + Location	• sn_customer_service_organization

• sn_csm_service_organization_member

• sn_csm_business_location | Use for agencies, brokerages, MGAs, branches, and producer staff. |
| Insurance Organization | User, Group, Role, Group Membership | • sys_user

• sys_user_group

• sys_user_grmember

• sys_user_role

• sys_user_has_role | Use for carrier employees, internal fulfillment, assignment, workspaces, and permissions. |
| Vendors / TPAs | Outsourced provider or service organization pattern | • sn_outsourced_service_provider

• service organization pattern where appropriate | Use for TPAs and external service or claims partners. Keep access scoped to assigned work. |

Relationships and Authority

The Authority band in Figure 2 is the bridge between People, Policy, and Work. It answers who can act, for whom, and in what capacity. Customer-level relationship access should be configured separately from policy-level authority.

Need	Table or configuration pattern	How to use it
Internal user manages an Account	sn_customerservice_team_member	Use for Account Team Member or Account Manager responsibility.
Internal user manages a Consumer	sn_customer_rel_consumer_to_user	Use for Consumer Team Member or Relationship Manager responsibility.
Internal user manages a Household	sn_customer_rel_household_to_user	Use for Household Team Member or Relationship Manager responsibility.
Consumer acts for another Consumer	sn_customer_rel_consumer_to_consumer	Use for authorized representative relationships between consumers.
Consumer acts within a Household	sn_customer_rel_household_member_relationship	Use for authorized representative patterns inside a household.
Producer of Record	Policy-level relationship / participant pattern	Do not assume this is only customer-level. Producer authority often varies by policy, line of business, coverage, or risk.
Named insured, additional insured, beneficiary	Policy Participant / Policy Participant Role	Introduce as an authority concept here; explain fully in the Product / Policy section.
TPA or adjuster works a claim	Claim / task / work assignment pattern	Keep access bounded to the assigned claim, task, document, or work item.

Before Moving to Product / Policy

Before moving into Product / Offering, Policy, Coverage, and Risk, confirm the people foundation. These decisions become harder to change later because they influence visibility, routing, reporting, delegated access, and work ownership.

Decision	What to configure before moving on
Is the customer an individual, business, household, or employer group?	Create the right CDF foundation: Consumer, Account, Contact, or Household.
Is a person acting for self or on behalf of another party?	Choose Consumer, Contact, Household Member, or authorized representative relationship.
Is the producer relationship customer-level or policy-level?	Capture customer-level relationships through SMF; defer policy-level authority to the policy / participant design.
Are producer organizations, carrier staff, and TPAs distinct?	Use separate service organization, member, outsourced provider, user, group, and role structures.
Does an external party need broad access or only work-specific access?	• Use relationship access for broad customer context
• use case, claim, task, or document assignment for bounded work access.
Does authority vary by policy, coverage, risk, claim, or service request?	Keep authority scoped to the right context so access and reporting remain accurate.

Key Takeaways

• People are the foundation of the insurance data model because they determine ownership, servicing access, authority, routing, and visibility.
• Policyholders, producers, carrier employees, and vendors / TPAs should remain distinct because they participate in the insurance value chain differently.
• Customer Data Foundation provides the primary records for consumers, accounts, contacts, and households.
• Service Model Foundation helps represent service organizations, service organization members, locations, relationships, and responsibilities.
• Authority should be scoped correctly. Some authority is customer-level, while other authority must be tied to a policy, participant, claim, task, or service request.

Learn More

For additional context on the platform concepts referenced in this section, review:

• Customer Service Management and CSDM tables
• Service Model Foundation
• Service Model Foundation relationships

People are in place. Next: what the carrier offers, what the customer holds, and how policy participants connect to it: Product / Offering, Policy, Coverage, and Risk, each building on that same foundation.

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