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.

[Stig Brandt]

I'm not sure, I see any duplicate in "catalog items", but maybe we don't have the same picture here.

For each - catalog Item, you need at least min. ONE Service Offering defined that owns the catalog item and is responsible for the demand etc.

the same is for Assignment Group, you need to have min. ONE Service Offering defined, to understand the service scope they are responsible to deliver.

[Barry Kant · Accepted solution]

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)

[CMDB Whisperer]

What Barry said.

[Matthew Swarts]

Agreed.  Many ServiceNow customers want their user base to have a more streamlined experience when using the Service Catalog to request things like Application Access, etc.  Having a separate catalog item for each individual application isn't scalable/maintainable nor is it user friendly.  The restriction that a catalog item can only be linked to one Service Offering makes accomplishing a maintainable, easy-to-use Catalog a bit more difficult.

[Debs McCann]

Could it depend on "who" is doing the work? If one team can provision the access to multiple applications, that would represent a different offering. So offerings based on applications, and also on support. Leaning on ITIL; a service request - can be made for goods, access, resources.  Leaning on the TBM council work; we would have offerings based at the Business Application and End-User levels, at least. I have just hit this issue in configuring DPM and wanting to attached catalog items to service offerings. It makes me think that the offering it's right, and needs tuning.