Catalog Item to Service Offering m:m

[Robert80]

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.

[Barry Kant]

hi Robert,

I do agree and I think it is a design error as it blocks catalog standardization concepts. 
It is known (to my knowledge) not entirely sure about the plans. 
It is also limited to catalog items, where it would also make sense to include record producers in my opinion. 

If that would all work fine then using Service Offering subscriptions the first catalog item filtering will be done based on these catalog item/service offering relation. User criteria (if needed) can be done on top of that. Meaning the catalog is making use of the offering subscriptions. (which makes sense to me).

Cheers,
Barry

[Paul Kilkelly]

I think there is, if you agree with these two definitions.

1. the purpose of a Service Offering is to provide a defined level of service to a community of subscribers around a defined scope.
2. the purpose of the Catalog Item is to request a ‘thing’: sometimes the ‘thing’ comes wrapped with a ‘service’.  

The relationship between the Catalog Item and the Service Offering is how ServiceNow link the ‘thing’ with its service wrapper.  E.g.  I order a server (the thing) which will be provided to me along with a guaranteed availability and tech support (the service offering).   

It makes sense then that I can wrap multiple things (requested by catalogue items) with the same service (a service offering).  

Of course, if I wanted to offer the same ‘thing’ with a number of service wraps then I’m going to need to use multiple catalog items for each permutation, and I can see that become unwieldy.  Perhaps you could separate the Catalog Item for the ‘thing’ from the CataIog Item for the ‘service wrap’, then use an order guide to to help the requester pick the right combo for them? 

[Stig Brandt]

Hi @Robert80 

Here is my take on this topic:

- Why ONE Service Offering to a Catalog Item

  - this is because you want to track who is responsible for Managing the "Catalog Item" - Requirements, Definition, Development, Test, Promote, Ticketing etc. (Managing the Catalog Item).

If the "Catalog Item" support many other offerings or used by other service offerings, I think is another relationship.

Best regards

Stig 

[CMDB Whisperer]

IMO while there is a correlation there it is heavy-handed to enforce that as a rule, especially given that the result is duplication of catalog items potentially resulting in inconsistencies which would lead to a negative user experience.  If anything it makes the most sense to consider the the service portfolio manager as the common "owner" of the catalog items for related service offerings, which would still allow service offerings to have different owners.