What Is the ServiceNow CRM Data Model?

Ask five people on a CRM implementation team where a customer's information "lives" and you'll usually get five different answers, depending on which product they work in. That's the wrong question in ServiceNow. Account, Contact, Product Model, Sold Product, Install Base Item, Contract, Entitlement, Case and Work Order don't live in Sales CRM, or in CSM, or in FSM. They live once, in a shared layer underneath all three, and each product just has a different window onto the same record. A technician dispatched through Field Service Management is looking at the same account history an agent already pulled up in a Customer Service Management case. A quote built in Sales CRM turns into an entitlement CSM can check automatically, with nobody picking up a phone to confirm it.

Most of the CRM implementations that end up with messy data didn't get the platform wrong. They got the boundaries wrong: someone built a second account table because it was faster than learning the shared one, or let a work order absorb everything a case should have owned. This article walks through what each object actually is, how they connect, and where teams typically trip over them.

The four layers, briefly

It helps to see where each object sits before getting into what it does.

The bottom layer does more work than people give it credit for. A Case in CSM, an Order in Sales CRM and a Work Order in FSM all extend the same platform Task table that an Incident extends in ITSM. That one shared ancestor is why all of them behave the same way under the hood: same state fields, same assignment logic, same SLA mechanics, without three separate teams having to build that consistency from scratch.

What is an Account and a Contact?

Account and Contact answer the "who" question, and everything else in the model eventually points back to one of them. An Account is a company: customer_account extends the platform's core_company record, so the organisation Sales CRM sees on an Opportunity is the exact same one CSM sees on a Case and FSM sees on a Work Order. A Contact is a person at that company. customer_contact extends sys_user, the same base table that holds every user in the platform, whether they're a customer, an agent or an internal employee.

Account and Contact hold:

• Company identity and hierarchy, including parent and child accounts
• A hub role: every Case, Contract, Opportunity and Work Order for that customer links back to the same Account
• Routing context, since Contact is what drives case routing in CSM, shows up on the Opportunity in Sales CRM, and is the site contact a technician sees in FSM

Not every business is B2B, though. Consumer and Household cover B2C and B2B2C models instead: Consumer is an individual customer, Household groups people who share an address or a set of products, with one person set as the head of household. Nothing stops a single instance from running Account/Contact alongside Consumer/Household, which is how a B2B2C company can serve a business customer and that business's own end users out of one data model.

What are Product Model, Sold Product and Install Base Item (Asset)?

These three track a product's whole life, from catalogue entry to sale to whatever's actually humming along at a customer site. Keeping them separate is what lets someone tell the difference between what a company sells, what a specific customer bought, and what's deployed at their location right now: three different questions that a lot of implementations quietly collapse into one.

• Product Model (cmdb_model) is the template, the definition of a product or service. Sales CRM extends it with pricing and bundling through Product Offerings; CSM references it for context on a case.
• Sold Product (sold_product) records that a particular Product Model was sold to a particular Account or Consumer. Sales CRM creates it when an order is fulfilled, and from that point on it's visible to CSM and FSM without anyone exporting anything.
• Install Base Item, or Asset (alm_asset), is the deployed, serialised instance: the physical unit sitting at a customer's site, linked back to a CMDB configuration item. This is the record a technician opens on a Work Order and an agent points to on a Case.

The distinction pays off exactly when something breaks. An agent troubleshooting a customer's issue doesn't need the entire history of a product line; they need the one Install Base Item this customer has, with its serial number and configuration history. A Sold Product with no matching Install Base Item is just a paper transaction. An Install Base Item with no Sold Product behind it is an asset nobody can trace back to a sale, a contract or an entitlement.

What are Contract and Entitlement?

Contract and Entitlement cover what a customer is actually owed. A Contract (ast_contract) defines the kind of support a customer gets, and it's usually created alongside the order during the sales motion. Entitlement is more specific: it spells out the SLA tier, support hours, and which channels (phone, chat, portal, a field visit) a given Account, Contact or Sold Product is covered for.

This is where the shared model earns its keep. Because Entitlement sits in the same CRM Foundation layer that Case reads from, CSM checks coverage automatically the second an agent opens a case. No manual lookup, and no risk of an agent working a case for someone whose contract expired months ago. The SLA engine underneath all of this (contract_sla) is a platform capability, not something CSM built on its own, which is why Entitlements and Contracts drive consistent SLA behaviour across Cases, Orders and Work Orders alike.

What is a Case?

A Case is CSM's object, and its job is to hold together everything an agent needs for one service interaction. It extends Task, and it exists to answer three questions: who is this customer, what do they own, and what are they entitled to. A Case ties Account/Contact, Product/Asset and Contract/Entitlement into a single record, no matter whether the interaction started on the phone, in chat, by email or through a portal.

A Case holds:

• The customer's description of the problem, plus whatever context an agent adds during triage
• A link to the relevant Sold Product or Install Base Item, so the agent knows exactly what's affected
• Auto-verified Contract and Entitlement data showing what level of support applies
• SLA tracking measured against the Case itself, not against any Work Orders it eventually spawns
• The full record of communication with the customer about that issue

A Case can close without a single Work Order attached (a question answered out of the knowledge base doesn't need a technician) or it can stretch across several, the way one reported issue sometimes needs diagnostics, a part swap and a follow-up visit before it's actually done.

What is a Work Order?

A Work Order belongs to FSM, and it's narrower in scope than a Case. A Case can take days and several visits to resolve; a Work Order tracks exactly one field assignment: a technician, a location, a time window and the labour performed. It extends Task and points to the same Account, Contact, Install Base Item and Entitlement records that CSM and Sales CRM already have, so a technician shows up already knowing what an agent knows.

A Work Order holds:

• Technician assignment, including scheduled start time and duration
• Location and access details for the site
• The specific job: replace a part, run diagnostics, do routine maintenance
• Labour and materials: hours worked, parts used, completion notes and photos
• Scheduling Optimisation data, a Foundation-level engine that routes technicians by location, skill and availability

Scheduling Optimisation deserves its own mention. It's part of the CRM Foundation, not something FSM built by itself, which is why the same dispatch logic is available to industry solutions with field operations (Telecom and Healthcare, for instance) without those teams having to reinvent it.

How they relate: a real example

A commercial customer's networking equipment starts dropping connections intermittently.

• Sales CRM, months earlier. The equipment sold as a Sold Product tied to a Product Model. A Contract with a 24-hour response Entitlement got set up as part of the deal, and an Install Base Item was created for the exact unit shipped to the site.
• CSM, day one. The customer calls in. An agent opens a Case against the Account and the affected Install Base Item. The Entitlement auto-verifies (24-hour response, phone and portal covered) and the Case's SLA clock starts right there, not whenever a technician eventually shows up.
• CSM, still day one. The agent can't fix it remotely and requests a field visit. No fresh research needed; the Account, Contact and Install Base data are already sitting on the Case.
• FSM, day two. A Work Order gets created, referencing the same Account, Contact and Install Base Item. Scheduling Optimisation assigns a technician by skill and proximity, who shows up already knowing the equipment's history.
• FSM, still day two. The technician finds a failing component, swaps it, and closes the Work Order with hours, parts and a completion note. Field execution is done there.
• CSM, later that day. The agent sees the Work Order closed, confirms with the customer that the connection issue is gone, and closes the Case. Elapsed time, coverage and resolution are all sitting in one record.

Nobody exported anything in that sequence, and nobody typed the customer's name into a second system. The Account from step one is the same Account referenced in step six, because there was only ever one.

Where organisations go wrong

Mistake 1: Recreating Accounts or Contacts per product

A team building out FSM, nervous about who owns what data, builds its own customer table instead of extending customer_account. Now a customer who calls CSM and later gets a field visit exists as two unrelated records, with nothing keeping them aligned. The fix is to extend the CRM Foundation objects rather than standing up a parallel one.

Mistake 2: Letting the Work Order do the Case's job

On simple, single-visit issues, teams sometimes skip the Case altogether and let the Work Order carry the issue description and the resolution notes. It works fine until the same piece of equipment fails again next month and there's no Case history showing the pattern, just a scatter of unrelated Work Orders. Open a Case for every customer issue, even the quick ones, and keep the Work Order as a pure execution record.

Mistake 3: Re-verifying Entitlements by hand

An agent doesn't trust the auto-verified Entitlement on a Case and calls sales to double-check coverage on every ticket. This is usually a training problem more than a data problem, but it defeats the entire point of the shared Contract/Entitlement layer and slows every single case down. Trust the auto-verification, and if it's wrong, fix the underlying Contract or Entitlement record rather than working around it.

Mistake 4: Forking the core objects inside an industry extension

A team building out a Telecom workflow adds fields and logic straight onto the base Account or Case tables instead of extending them the way Industry Workflows are meant to. A platform upgrade later breaks all of it, because none of the customisation sat on the extension points the architecture actually expects. Extend, don't fork.

Business impact: the cost of confusion

Once an Account or Contact exists in two places, there's no longer a single answer to what a customer owns or what they're entitled to. Agents end up making decisions off whichever copy happens to be in front of them, and reporting fragments the same way: revenue numbers pulled from one Account record, support metrics from another, with no way to reconcile the customer's full relationship with the company.

If a Work Order is carrying case-level information and Cases are getting skipped for the easy stuff, SLA reporting starts measuring field response time instead of how long the customer actually waited. Leadership sees good numbers. Customers who sat on hold before a Work Order was even opened experience something much slower. That gap is exactly what keeping Case and Work Order separate is supposed to prevent.

And teams that don't trust the shared model tend to build integrations to keep their duplicate records in sync (middleware, scheduled jobs, reconciliation scripts) to manually recreate a unification the platform already gives away for free. That integration layer becomes its own maintenance headache, and it's usually the first thing that breaks during an upgrade.

What we'd actually do: practitioner judgement

On any CRM build of real size, the first architecture call isn't which fields to add. It's committing to build on top of the CRM Foundation objects instead of around them. Every new requirement gets checked against one question: does something like this already exist in Account, Contact, Product Model, Sold Product, Install Base Item, Contract or Entitlement? If it does, extend it. If it genuinely doesn't, that's what Industry Workflows and custom extensions are for, not a reason to stand up a parallel table.

We'd also lean hard on the Case/Work Order boundary, because it's the one teams collapse fastest when a deadline is close. A Case gets opened for every customer issue, no exceptions, even the ones solved on the first phone call. That habit is what keeps SLA reporting honest and lets patterns across repeated equipment failures actually surface later, and it costs almost nothing once agents are trained to do it by default.

And we'd treat the auto-verification behaviour (Entitlements checking themselves the second a Case opens, Sold Products showing up in CSM the moment Sales CRM fulfils an order) as something worth protecting rather than second-guessing. The urge to manually double-check it usually comes from scar tissue with a different platform's integration layer. There isn't one here to distrust. There's just the one record.

The honest concession: when this gets harder

None of this comes for free. Committing to the shared model means every team (Sales CRM, CSM, FSM and whatever Industry Workflow sits on top) has to actually agree not to fork the objects they share, and that takes governance, not just good intentions. On a small, single-product deployment (CSM on its own with no field service and a simple sales motion) the discipline around separating Case and Work Order matters a lot less, since there's no Work Order in the picture to begin with.

It also means that when something looks off on a Case (a stale Entitlement, a missing Install Base Item) the fix belongs on the source object, not a patch on the Case itself, because that same record is visible everywhere else too. That's the right long-term call, but it can mean a few extra minutes tracing an issue back to where it actually started instead of just patching around it locally. Teams coming from platforms with per-product data silos usually find that habit, fixing things at the source, harder to adopt than any of the object names.

Frequently asked questions

Is an Asset the same thing as an Install Base Item?

Pretty much. Install Base Item is the CRM-layer term, and it's backed by the same alm_asset table used elsewhere on the platform. When someone says "asset" in a CRM conversation, they almost always mean this record: the specific, serialised, deployed unit a customer owns, as opposed to the Product Model it was built from.

Can a Case exist without a Work Order?

Yes. A question answered straight out of the knowledge base, or an issue closed on the first call, ends as a Case with no Work Order attached at all. Not every Case needs a technician.

Does a Work Order need a Case?

It should reference one. A Work Order floating with no Case behind it is field labour with no record of why it was requested, which makes it hard to tell later whether the customer's actual problem got solved.

What's the difference between a Sold Product and an Install Base Item?

A Sold Product is commercial: this Account bought this Product Model. An Install Base Item is operational: this specific serialised unit sits at this location. A single Sold Product, a bulk order, say, can map to several Install Base Items at once.

How is an Entitlement different from a Contract?

A Contract is the broader agreement, the kind of support a customer bought. An Entitlement is the detail underneath it (the actual SLA tier, hours and channels) which is the part that gets checked against a Case.

Do Industry Workflows use their own Account and Case objects?

No, and that's kind of the point of the layered architecture. A Telecom agent and a general CSM agent are working with the same Account, Contact, Case and Entitlement objects underneath. What changes is the workspace, the playbooks, and whatever domain-specific entities (a Subscriber, a Patient) the Industry Workflow adds on top.

Summary

The ServiceNow CRM data model comes down to four layers built on top of each other, not four systems bolted together. Account and Contact establish who the customer is. Product Model, Sold Product and Install Base Item track a product from catalogue entry to deployed asset. Contract and Entitlement spell out what a customer is owed. Case and Work Order are the records that pull all of it together, one tracking the customer's issue, the other tracking the field work. Every object exists exactly once, and Sales CRM, CSM and FSM all see it in real time. Respect that boundary and you get a genuinely unified sell-fulfil-service experience. Ignore it, and you end up rebuilding by hand the unification the platform was already giving you.