- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
2 hours ago - edited 2 hours ago
A while back, I wrote about the differences between sold products and installed base items, and how to manage the customer service data model in ServiceNow. I know that creating these records manually and linking them to each other—and then aligning everything with the CMDB—can be tedious and time-consuming.
So in this article, I want to explore something different: Is there a way to automatically provision sold products, installed base items, link them together, and align them with the CMDB?
The answer is yes.
First we need to think about ServiceNow as an enterprise platform—a single system of record that connects the entire organisation.
Think about it:
- Sales and Order Management (SOM) captures what customers buy.
- Customer ServiceManagement(CSM) supports your external customers when they need help with products you've sold them
- IT Asset Management (ITAM) manages the lifecycle of those products
- IT Operations (ITOM) proactively monitors infrastructure and raises incidents when issues occur
The Automated Journey: From Order to Support
Here's where the magic happens. With ServiceNow's automation capabilities, you can create an end-to-end automated process:
1. It Starts with an Order
A customer places an order through your Order Management. This is the trigger.
2. Automatic Provisioning via Flows
Once the order is created, flows automatically:
- Create the Sold Product record
- Create the corresponding Installed Base Item (IBI)
- Link the sold product to the installed base item
- Link the installed base item to the correct Configuration Item (CI) in your CMDB
No manual work required. No risk of human error. No delays.
A Real-World Example: SaaS Software Provider
Let me walk you through a concrete example to make this clearer.
Imagine a technology provider that sells SaaS software( lets say they sell CSM plus). A customer logs into the business portal to purchase the software. The technology provider offers this SaaS solution as their primary offering.
The Product Catalog Structure
From a product catalog perspective, the offering is built from three layers:
- Product Specification – Represents the main sold product (the SaaS software itself)
- Service Specification – Represents the service layer, linked to an Installed Base Item and an Application Service
- Resource Specification – Linked to another Installed Base Item and a CI representing the VM that the application service depends on.
How the Automation Works
Step 1: Customer Purchase
The customer completes their purchase through the portal.
Step 2: Fulfilment Policy Triggers
A fulfilment policy activates a flow with IntegrationHub capabilities.
Step 3: Automatic Provisioning
IntegrationHub flows automatically provision:
- Development and Production instances.
- VM machines to support those instances
Step 4: CMDB Population
The VMs and Application Services are created as Configuration Items in the CMDB.
Step 5: CSM Linkage via Installed Base Items
The flow creates Installed Base Items for both:
- The Application Service (linked to the Service Specification)
- The VM (linked to the Resource Specification)
These IBIs are automatically linked to the Sold Product, creating a complete chain of visibility.
The Architecture in Action
Now you have a fully connected architecture:
- Customer owns a Sold Product (the SaaS Product)
- The Sold Product links to Installed Base Items (service layer and infrastructure layer)
- Those IBIs map to CIs in the CMDB (Application Service and VM)
- IT Operations monitors those CIs
All of this happens automatically through flows—no manual intervention required.
Example of Product created automatically from Order management
Example of Application Service and VM created via automation linked to order management
If you're licensed for Event Management, this is where things get really powerful.
The CI linked to your sold product and installed base item becomes the object you're monitoring. When an event occurs on that CI:
- An alert is logged
- The system knows which customer is impacted
- IT can proactively manage the incident through the ITSM lifecycle
- You can notify the customer before they even notice the issue
This connected model transforms how organisation operates:
For Customer Service: Agents instantly see what a customer owns, what's installed, and if there are any active issues—all in one place.
For IT Operations: When infrastructure fails, you immediately know which customers are affected and can act proactively.
For the Business: You get a unified view of the customer journey from sale through support, with real-time visibility into product health and customer impact.
