This article gives an overview of the different Catalog relationships supported by ServiceNow Catalog Management under the TSM Application.
Feature: Catalog Relationships
Application: Telecom Service Management
Release: All applicable
DYK (Did You Know) is a series of articles that introduces simple and basic concepts of the working of ServiceNow TMT Applications.
ServiceNow Catalog is aligned with the TMF SID (Shared Information Data Model) and provides the following entities to express the Catalog definition –
Product Offering
Product Specifications
Service Specifications
Type = customer facing
Type = resource facing
Resource Specifications
These entities can be categorized in the following domains –
Product Domain contains Product Specifications
CFSS Service Domain contains Customer Facing Service Specifications
RFSS Service Domain contains Resource Facing Service Specifications
Resource Domain contains Resource Specifications
Intra Domain relationships.
A hierarchical relationship between two specifications of the same type i.e., ONLY within a given domain can be expressed either via a ‘Bundles’ or ‘ComposedOf’ relationship.
When should a 'Bundles' relationship be used?
A Bundles relationship is similar to a ‘Aggregation Relationship’.
A Bundles relationship should be used when:
- The target specification in the relationship may remain unaffected by a change on the source specification.
- The target specification may change or cease independent of the source specification.
- The instantiated target specification can have its independent orchestration flow.
In a Bundles relationship, a Domain order is created for both the source and target specification and hence may have an orchestration Subflow attached to both the domain orders.
When should a 'ComposedOf' relationship be used?
A ComposedOf relationship is similar to a ‘Composite Relationship’.
A ComposedOf relationship should be used when:
- The target specification in the relationship is always affected by a change or cease of the source specification.
- The target specification does not change or cease independent of the source specification i.e., it’s lifecycle is tightly coupled with the source specification.
- The instantiated target specification does not have its independent orchestration flow.
In a ComposedOf relationship, a Domain order is created only for both the source specification and hence can only have an orchestration Subflow attached to the domain order for the source specification.
Inter Domain Relationships
A hierarchical relationship between two specifications of different type i.e., ACROSS domains can be expressed either via a ‘Realized As’ or ‘Requires’ relationship.
When is a ‘Realized As’ allowed?
In a hierarchical relationship, when the target specification is of type CFSS, the relationship type to used is ‘Realized As’.
When is a ‘Requires’ allowed?
In a hierarchical relationship, when the target specification is of type RFSS or a Resource, the relationship type to used is ‘Requires’.
The table below summarizes the specification relationship types –
|
Source Specification |
Target Specification |
Supported Relationship Types |
Intra/Inter Domain Classification |
|
Product |
Product |
Bundles, ComposedOf |
Intra |
|
Product |
CFSS |
Realized As |
Inter |
|
Product |
RFSS |
Requires |
Inter |
|
Product |
Resource |
Requires |
Inter |
|
CFSS |
CFSS |
Bundles, ComposedOf |
Intra |
|
CFSS |
RFSS |
Requires |
Inter |
|
CFSS |
Resource |
Requires |
Inter |
|
RFSS |
RFSS |
Bundles, ComposedOf |
Intra |
|
RFSS |
Resource |
Requires |
Inter |
|
Resource |
Resource |
Bundles, ComposedOf |
Intra |
Horizontal Relationships
While hierarchical relationship is top-down/vertical/parent-child in nature, ServiceNow Catalog also supports horizontal relationships that cuts across domains or hierarchy and is agnostic to whether the source and target specification have a common parent.
Horizontal Relationship is like a dependency relationship, where one entity relies on another entity.
Within horizontal relationship there are two types supported – ‘Requires’ and ‘Excludes’.
Horizontal relationship is also known as sibling relationship.
Note: The ‘Requires’ in a hierarchical relationship is different from the ‘Requires’ in a horizontal relationship.
When to use horizontal relationship?
Here are a few scenarios where horizontal relationships are useful –
- When creating a relies on/requires relationship between two specifications, irrespective of whether they have a common parent or part of common offering.
- Example: A VoIP service depends on a Broadband Product.
- When grouping specifications by a common source specification.
- Example: In scenarios where there are multiple Broadband, VoIP and OTT services, and there is a need to identify which VoIP and OTT depends on which Broadband service under a given Account.
- When defining mutually exclusivity between two specifications.
- Example: VoIP service cannot be offered over Mobile Broadband and hence excludes (is mutually exclusive) with it.
More information on how to configure horizontal relationships is available in ServiceNow Product documentation here –
Let us use these concepts and apply it to a real Catalog model below.
Takeaways from this Catalog model –
- Home Office Internet and a Router are sold as two independent offers.
- Home Office Internet Product has a hierarchical relationship with –
- 24/7 Support Product of ‘ComposedOf’ type, since the Support product’s lifecycle is tightly coupled with the source specification and does not need a separate orchestration Subflow of its own.
- Email Account Product of ‘Bundles’ type, since the Email Product has a set of characteristics such as mailbox size that can change independent of the source specification and it also has an independent orchestration Subflow to provision the mailbox.
- Connectivity Service (CFSS) is delivered either over Fibre or DSL Access (RFSS).
- Fibre Access ‘Requires’ (horizontal) a Fibre ONT resource, but ‘Excludes’ a DSL Modem.
- DSL Access ‘Requires’ (horizontal) a DSL Modem resource, but ‘Excludes’ a Fibre ONT.
- Notice that the source & target specifications in the horizontal relationship between the Access and Router/ONT are under two independent Catalog structures.
- Also notice, the different relationship types in the context of intra and inter domain.
If you found this article useful, please mark is as Helpful 👍. Also, I look forward to your comments/questions.
I am getting above error when publishing CFSS in relationship with RFSS.
Pls advise what could be reason on this errors and how to rectify.
This is what you are looking for or any other details.
Hi @ShashankInamdar ,
I am also facing the same issue. Earlier, the relationship type between CFS and RFS is requires. But now, when I am publishing, it says this error.
