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: Overview for 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.
