- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-10-2022 08:42 PM
Howdy
Is there a reason why the data model only allows mapping a catalogue item to one service offering?
For context, I have a catalog item which is used to request access to an application service. Users can request access to either production or training environments on the same form. I have an offering for production and an offering for non-production because they have different availability KPIs.
It would be helpful to map multiple offerings to one catalog item and I'm not sure why it's not available OOTB.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-11-2022 06:25 AM
I understand the concept, but in my opinion the catalog item is a construct to facilitate a Service Offering.
When it is 1:n (as is now) it blocks the option to standardize the catalog as such. With 1000 applications you might have a high repeating number of catalog items because it can be linked to 1 offering.
It has a huge maintenance effect and a huge performance impact.
And a usability impact. Users will not find the catalog item needed.
Catalog Items can be flexible/dynamic and still serve the same purpose. It doesn't need to tie to a single service offering. (not necessarily)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-12-2023 07:29 AM
It looks like the 1:n relationship is coming from the technical domain, where a single technical offering is responsible for providing the service and contains information on the change and support groups for the item.
Unfortunately this definition is now used for sell/consume domain purposes, where an item "Standard laptop" should be part of several Business Service Offerings and a design mistake is promoting the technical 1:n relationship for this purpose.
Technical offering:cat item 1:n and Business offering:cat item n:n relationships are both needed. This is a frequent functionality request from the customers and it would be wonderful to see a SN solution for the same.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-11-2022 06:54 AM
Yeah you're right, my comment was looking at it backwards. The actual problem here is that this relationship constrains your ability to define your Service Offerings in a way that meets your service portfolio management strategy.
The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-11-2022 05:57 AM
I agree that this is a design issue. This is backed up by the fact that this actually works differently based on whether or not you have Service Owner Workspace installed.
The opinions expressed here are the opinions of the author, and are not endorsed by ServiceNow or any other employer, company, or entity.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-17-2022 10:48 AM
In the meantime, does anybody have a good workaround? Create your own related list or List type field, and make your own relationships?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-17-2022 10:21 PM
We can link catalog item to multiple Service offering, there is M2M table but agree with Barry as well.
Again, it depends on the requirement.
sc_cat_item_subscribe_mtom -> OOTB M2M table to link catalog Item to BSO which is part of subscription.
