A sold product is the ServiceNow record (sn_install_base_sold_product) that captures what a specific Account or Consumer actually bought: which Product Model, at what price, under which Service Offering. It's created the moment an order is fulfilled, and it's the record a fulfilment flow action uses to generate an install base item, the deployed asset a customer service agent or technician sees months or years later. Small object, load-bearing job: without it, order fulfilment and aftermarket service don't actually connect.
What is a Sold Product?
A sold product is the record of a transaction: proof that a specific Account or Consumer bought a specific Product Model or Service Model, at a specific price, under a specific Service Offering. It lives on the sn_install_base_sold_product table, part of ServiceNow's Customer Service Management and Common Service Data Model (CSDM) tables, and it exists to answer one question cleanly: what did this customer actually buy?
It's commercial, not operational. A sold product doesn't know where the product is deployed, whether it's working, or who's using it day to day; that's the Install Base Item's job. The sold product's job is narrower and more specific: hold the transaction, and reference the catalogue entry it came from.
How is a Sold Product different from an Install Base Item?
A sold product is commercial; an install base item is operational. The sold product says an Account bought a Product Model. The install base item (sn_install_base_item) says a specific, provisioned instance of that product is deployed somewhere: for a SaaS product, that's typically a configuration item referencing an application service; for a physical product, it's the actual unit at a customer site.
The two connect through a third table most people never think about: Installed Products (sn_install_base_m2m_installed_product). That join table is what allows a single sold product to map to an install base item, and supports the messier real-world case where multiple sold products (add-ons, upgrades, renewals) all point to the same deployed instance over its life.
How does a Sold Product actually create an Install Base Item?
A sold product creates an install base item through a fulfilment flow action, not a separate manual step someone has to remember. ServiceNow ships a standard flow action called "Create Install Base Item and Installed Product," built for use inside order fulfilment subflows in Workflow Studio.
The mechanics are specific enough to be worth naming exactly:
- Input. The flow action takes three things: the customer order line being fulfilled, a configuration item (CI), and the sold product created for that line.
- Creation. It creates the Install Base Item, linking it to the CI it represents: an application service CI for SaaS, a physical asset for hardware.
- Linking. It creates the Installed Product record joining the new Install Base Item to the Sold Product, so the commercial and operational sides of the same purchase stay connected.
Nobody has to remember to "set up" an install base after the sale closes. If the fulfilment subflow runs the standard flow action, the install base exists the moment fulfilment completes, which is exactly why this small object is load-bearing. Skip it, or fork the fulfilment flow without it, and Order Management can close a fulfilment task while CSM has no idea the customer owns anything.
Why does the Sold Product matter more than it looks like it should?
The sold product matters because it's the only record that sits on both sides of the sell-to-service handoff. Order Management owns the moment of fulfilment. Customer Service Management owns everything that happens to the customer afterward: a case, an entitlement check, a field visit. Nothing forces those two worlds to agree on what the customer actually has; except the sold product and the install base item it generates.
That's why a broken or missing sold product doesn't fail loudly. Fulfilment still closes; the customer still gets their product. What breaks is everything downstream: an agent opening a case six months later with no install base to reference, no entitlement to check, no way to tell what this customer owns without asking them. The failure is invisible at the moment of sale and expensive the first time someone needs it.
Where do teams get the Sold Product wrong?
Custom fulfilment flows that skip the standard flow action. A team builds its own fulfilment subflow for a complex order type and forgets to call "Create Install Base Item and Installed Product." The order fulfils; the install base never gets created.
Treating the sold product as a static record. Upsells, downsells and renewals change what a customer owns over time. Recent Install Base releases added split-from lineage tracking specifically so upgrades don't just overwrite history; teams that don't use it lose the ability to explain how a customer got to their current configuration.
Pricing drift between the sold product and the actual contract. The sold product now carries its own pricing and pricing-adjustment data. If that's left blank or inconsistent with the Contract and Entitlement records, an agent gets two different answers to "what is this customer paying" depending on which record they check.
What would we actually do, implementing this for a client?
We'd treat the standard "Create Install Base Item and Installed Product" flow action as a default, not an optional building block: any custom fulfilment subflow gets checked against it before go-live, specifically to confirm the install base still gets created for every order type, not just the common ones tested in the demo. The failure mode here doesn't show up in fulfilment testing; it shows up three months later in a CSM case, which is exactly the kind of gap that's expensive to trace back.
We'd also insist pricing on the sold product and pricing on the Contract stay reconciled, rather than letting two systems of truth quietly diverge. If your fulfilment flows are custom enough that you're not sure the install base is being created reliably, that's the kind of audit we do at Impactron.
Where does this model get more complicated than it looks?
The sold product model is straightforward for a single product sold once. It gets genuinely harder the moment a customer's ownership changes shape over time: an upsell that should extend an existing install base rather than create a duplicate one, a downgrade that should shrink an entitlement without deleting history, a renewal that should carry pricing adjustments forward. ServiceNow has been actively building for this (split-from lineage, billing account references, derived pricing all landed within the last year of releases), which is itself a signal that the out-of-the-box model alone hasn't fully solved it yet. Teams with straightforward, one-time sales won't feel this. Teams with complex subscription or upgrade paths should expect to spend real design time here, not treat it as a checkbox.
Frequently asked questions
Is a sold product the same as an asset?
No. A sold product is the commercial record of a purchase. The asset (the actual deployed instance) is the Install Base Item. They're linked, not identical.
Does every order create a sold product?
It should, for anything Order Management fulfils that's meant to be tracked afterward. Whether it does in practice depends on the fulfilment subflow actually calling the standard flow action or an equivalent custom step.
Can one install base item have more than one sold product?
Yes. The Installed Products join table supports this deliberately, which is how add-ons, upgrades and renewals on the same deployed instance stay connected to their individual sales records.
What happens if the install base item is never created?
The order still fulfils, but CSM and FSM have nothing to reference for that customer's purchase. Cases can't link to the right asset, entitlements can't be checked automatically, and agents end up asking customers to describe what they own.
Summary
A sold product is a small, specific record (what an Account bought, at what price, under what offering) but it's the hinge the whole sell-to-service handoff turns on. A standard flow action turns it into an Install Base Item the moment fulfilment completes, linking the commercial fact of the sale to the operational reality of what's deployed. Skip that step, or build around it without noticing, and Order Management and CSM stop agreeing on what your customers actually own.