The previous article explained the PSR model: product offerings on top, then product, service and resource specifications underneath. This one moves from concepts to the configuration screens.
It covers four tasks that come up on almost every Sales CRM and SOMT implementation: classifying specifications with CMDB model categories, building bundles, copying products and specifications, and
mapping dependent characteristics between specifications.
| Out-of-the-box only: every step here uses standard ServiceNow configuration — forms, related lists, relationship types and rules. There are no scripts, no customizations and no extension points. |
New to the series? Start with Sales CRM Decoded: The Big Picture.
In this article
# | Section | What you will learn |
— | Before you start | The roles you need and the order to build the catalog in |
1 | Classifying specifications with CMDB model categories | How specification categories link to model categories, and how to choose CI, asset and install base classes aligned to CSDM 5 |
2 | Building bundles | Bundles vs Composed of at the specification level; relationship groups and offering relationships at the offering level |
3 | Copying products and specifications | When to use Copy and when to use Create New Version, and what each does to version lineage |
4 | Mapping dependent characteristics | How attribute mappings carry a value from one specification to another, and the five action types |
— | Checklist before you publish | Eight checks to run before a catalog change goes live |
Before you start
All four tasks happen in the CRM Workspace (List view) or under All > Product Catalog Management, and need one of these roles:
Role | Used for |
sn_prd_pm.product_catalog_manager | Specifications, offerings, versions, copies, attribute mappings and offering relationships |
sn_prd_pm.product_catalog_admin | Characteristics and offering relationships. The relationship group docs list both the admin and manager roles. |
Build the catalog in this order, so that every record you reference already exists and is published:
- Characteristics and characteristic options
- Model categories (CMDB) and specification categories
- Resource, then service, then product specifications — each published before it is used
- Attribute mappings and specification relationships
- Product offerings, bundles and relationship groups, then publish to a catalog
1. Classifying specifications with CMDB model categories
Every specification has a Category field that points to a specification category. The specification category, in turn, is attached to a CMDB model category. That single link is what ties your catalog to the CMDB: the model category carries the CI class, asset class and install base item class that apply to every specification in the category.
What a model category carries
A model category is a standard CMDB and Asset Management record. The fields that matter for the catalog are:
Field | What it does |
CI class | The CMDB class for configuration items in this category. It can be set only when the category is created. |
Product model class | The product model class associated with the category. |
Asset class | The asset class (for example Hardware, Software License or Consumable). Once selected, it cannot be changed. |
Install base item class | The class used to track the item as an install base item. Appears only when Customer Service Install Base Management is installed. |
Allow in bundle / Allow as main | Whether items can be part of a bundle, or the main item of one. Available only when an asset class is set. |
Enforce CI verification | Stops assets being created automatically for CIs added manually or by Discovery, so they can be reviewed first. |
How to set it up
- Check the base system first. ServiceNow ships many model categories, and the CMDB CI Class Models store app provides the CSDM 5 Service Instance classes. Reuse a category whose CI class and asset class already match what the specification represents before creating a new one.
- Create a model category only when nothing fits. In the Australia release: Enterprise Asset Workspace > Admin center > Model categories > New (Enterprise Asset Management roles), or Product Catalog > Product Models > Model Categories in the classic UI. Choose the CI class carefully — you cannot add it later.
- Attach the model category to the specification category, so every specification in that category shares one CMDB classification.
- Select the specification category on each specification through its Category field before you publish.
Aligning with CSDM 5
CSDM 5, ServiceNow’s current Common Service Data Model, changes what “the right CI class” means for a telecom or technology catalog. Four changes matter most when you choose model categories:
- Service Instance replaces Application Service as the umbrella - The table cmdb_ci_service_auto is now labelled Service Instance, and application services sit underneath it as one kind of instance.
- New Service Instance classes cover what telecom catalog deliver - Network, Connection, Data, Facility and Operational Process service instances. CSDM 5 model connections such as a VLAN, LAN or WLAN as CIs, so impact analysis can follow them.
- Product model classes are not CMDB classes - Products live in cmdb_model through product model classes, and CIs point to their model through the Model ID attribute. CSDM 5 adds new product models, including the Service Offering Model and the System and Software Component Models.
- Install base items connect sales to delivery. - Customer Service references the Service Delivery tables through the install base item (IBI). With Product Instance 2.0 enabled, the life cycle stage and status stay in sync between the CI, the asset and the IBI.
The table below suggests a CSDM 5-aligned CI class for each PSR layer. It is a starting point for the conversation with your CMDB owner, not a fixed rule — always confirm the class exists on your instance.
PSR layer | Typical example | CSDM 5-aligned CI class for the model category | Asset class |
Resource — physical | ONT, router, CPE | The matching network-gear hardware class in the base CMDB (for example IP Router) | Hardware |
Resource — logical connection | Access bearer, circuit, VLAN | Connection Service Instance (cmdb_ci_connection_service_instance) | None |
RFSS — network service | IP addressing, core network functions | Network Service Instance (cmdb_ci_network_service_instance) | None |
RFSS — data service | Data platform or feed | Data Service Instance (cmdb_ci_data_service_instance) | None |
CFSS / sold product | Internet Access for one customer | Service Instance (cmdb_ci_service_auto) or the closest subclass, tracked through the install base item class | None |
Software and licences | Router OS, security subscription | Software classes; the Software License asset class makes the CI class read-only | Software License |
Service Instance subclasses are delivered by the CMDB CI Class Models store app (version 1.64.0 and later) and documented in the CSDM 5 white paper. Network functions themselves are modelled in Telecom Network Inventory, a separately licensed app.
Choosing the right model category
- Reuse before you create. Start from base-system model categories and the classes CSDM 5 already provides. Creating custom CI classes is outside the out-of-the-box approach this article follows.
- Match the asset class to what you really track. Physical equipment needs a hardware asset class; service instances usually need none; Consumable and Software License make the CI class read-only.
- Set the install base item class for anything the customer owns or consumes, so service teams see the same record after the sale.
- Check older categories. Categories created before CSDM 5 may point to classes that were since relabelled, such as Application Service. Because the CI class cannot be changed, create a new CSDM 5-aligned category instead of editing the old one.
Decide early: because the CI class is fixed at creation and the asset class cannot be changed once selected, agree the category design with your CMDB and asset owners — against CSDM 5 — before the first specification is published.
2. Building bundles
Bundling happens at two levels, and they solve different problems. Specification bundles decide how a product is built and fulfilled. Offering bundles decide how it is packaged and sold.
Bundles in the specification layer
Mark the parent product specification as Composite and relate its children with the right relationship type. The choice matters, because it decides which domain orders are created:
Relationship | Behaviour | Use it when |
Bundles | Aggregation. The bundled child can change or be retired independently and gets its own domain order. | The child has its own lifecycle, such as an email mailbox inside an internet product |
Composed of | Composition. The child's lifecycle is tied to the parent; only the parent gets a domain order. | The child only exists as part of the parent |
Realized as | Links a product specification to the customer-facing service that delivers it. | Moving from the product layer to a CFSS |
Requires | Links to an RFSS or resource; horizontally, marks a dependency between siblings. | A service needs a technical service or resource |
Excludes | Horizontal: two specifications cannot be ordered together. | Mutually exclusive options |
Relationship behaviour as described by ServiceNow in DYK: How to use different relationship types in a TSM product.
Bundles in the offering layer
A bundle offering packages several product offerings so customers can order them together. It is built from two standard related lists on the parent offering.
Step 1 — create relationship groups. Open the parent offering (Offerings > Product Offerings), select the Product Offering Relationship Groups tab and select New:
Field | Meaning |
Name / Description | The group name shown to the user, such as Modem or Internet |
Order | Where the group appears in the product configurator |
Min options / Max options | How many choices must or can be made in the group |
Step 2 — add product offering relationships. On the Product Offering Relationships tab, select New for each child:
Field | Meaning |
Target product offering | The child offering being bundled (a single offering or another bundle) |
Relationship type | None (no relationship between the bundled products) or Implicit (an implicit relationship) |
Product offering relationship group | The group the child belongs to |
Mandatory / Default | Whether the child is required, and whether it is pre-selected |
Default, Min and Max quantity | Quantity limits for the child within the bundle |
Unit of measurement | Unit for the bundled product, such as Box or Case |
Step 3 — decide how characteristics flow. When an offering references a specification hierarchy, select Copy child specification characteristics to inherit characteristics from the child specifications as well as the parent. On the bundle offering itself you can add characteristics (such as order enrichment attributes) or remove inherited ones you do not want to show.
ServiceNow supports three bundle shapes: a top-level offer with nested offers and no specification; nested offers where any level references a specification; and two or three levels where the leaf offer references a specification hierarchy. When a bundle is quoted or ordered, each transaction line carries both the offering and the specification reference, and Order Management creates the domain orders and the sold product and product inventory records.
3. Copying products and specifications
ServiceNow gives you two standard ways to reuse an existing record, and they mean different things. Use Create New Version when the same product changes. Use Copy when you want a new product that starts from an existing one.
| Create New Version | Copy |
Purpose | Change an existing product or specification | Start a separate product or specification from existing data |
Version number | Next increment (2, 3, …) | Starts again at 1 (a new base version) |
Lineage on a specification | Initial and Previous Version link to the original | Initial and Previous Version are blank — no link to the source |
Lineage on an offering | Initial and Previous Version link to the original | Initial Version is set to the source offering; Previous Version is blank |
Prerequisite | The base version must be Published | Available from the record's actions |
How to do it
- Open the specification (Specifications > Product, Service or Resource) or the offering (Offerings > Product Offerings).
- Select Create New Version for a change to the same product or Copy for a new product.
- Review the related lists: Specification Characteristics, Specification Relationships and Attribute Mappings on a specification; Product Offering Characteristics and Product Visuals on an offering.
- Select Update to save as a draft or publish to make it available. A published record cannot be changed or deleted — the next change is another version.
Watch out: a retired specification version cannot be used in a product offering or to create new versions. Retire old versions only after every offering that needs them has moved on.
4. Mapping dependent characteristics
Often a value chosen in one specification should drive a value in another. For example, ordering a managed router on a broadband product should set the right options on the CPE management service. ServiceNow handles this out of the box with attribute mappings, so fulfilment agents never re-enter the same data.
How to create an attribute mapping
- In the CRM Workspace (List view), go to Specifications, choose Product, Service or Resource, and open the specification.
- Open the Attribute Mappings tab and select New.
- Select the Source specification, then move the source characteristics you need from Available columns to Selected columns.
- Select the Target specification.
- In Conditions, use the condition builder to state when the rule applies, then Save. The source and target rule names are generated.
- Choose the target characteristics to use as action variables.
- In Actions, select New and set the Action type, the Action and the source Variables, then Save.
The five action types
Action type | What it does to the target characteristic |
Defaulting | Provides a default value for the target characteristic |
Set value | Sets the target value, for example by copying it from the source characteristic |
Inclusion | Includes or enables characteristics or options |
Exclusion | Excludes, disables or deselects characteristics or options |
Validation | Validates the values chosen |
Rules worth knowing
- Mappings can link any specifications in the product and service hierarchy: parent to child, child to parent, siblings and horizontal relationships.
- Source and target can use the same characteristics or different ones, including complex (Object) characteristics.
- When specification relationships and decomposition rules exist, the platform validates each new mapping to make sure it is unique and does not break decomposition.
- If a decomposition rule depends on a mapping, decomposition waits for the mapped value. The platform warns you (“Attribute mapping rule impacts decomposition rule…”) — remove the dependency rather than ignoring the warning.
- For dependencies inside one characteristic, such as a parent attribute with child attributes, use an Object characteristic with characteristic relationships instead of a mapping.
Checklist before you publish
- Every specification has a specification category, and each category has the right model category.
- Model categories reuse base-system records where possible, use CSDM 5-aligned CI classes, and were agreed with CMDB owners.
- Composite is set on parent specifications, and Bundles vs Composed of is chosen deliberately.
- Relationship groups have sensible Min and Max options, and mandatory and default children are set.
- Copy child specification characteristics is selected where the offering needs child characteristics.
- Changes to existing products use Create New Version; only genuinely new products use Copy.
- Attribute mappings save without validation warnings against decomposition rules.
- The Catalog Hierarchy tab shows the expected tree from offering to resource.
Thank you
Thank you for reading. Each of these four tasks can be done entirely with the platform as it ships, and staying out of the box keeps your catalog easy to upgrade.
If you found it useful, please mark it helpful, share it, and follow me on LinkedIn. Questions and experiences are very welcome in the comments.
References
- Manage model categories (Australia)
- CSDM 5 white paper (ServiceNow Community)
- Application Service and Service Instance: what is new in Yokohama and CSDM 5 (ServiceNow Community)
- Product offer bundling with product specifications
- Create product offering relationship groups
- Create product offering relationships
- DYK: How to use different relationship types in a TSM product (ServiceNow Community)
- Create and publish product specifications (Australia)
- Create and publish a specification version (Australia)
- Create and publish a product offering version (Australia)
- Create and publish your product offerings to a catalog (Australia)
- Define domain order attribute mappings (Australia)
- Defining mappings for attribute value propagation to domain orders
- Create product characteristics and characteristic options (Australia)
- Retiring or archiving versioned specifications and product offerings
