- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi, How can I use the same catalog item, say Requesting access to a Business application for multiple Business applications under the multiple business service offering. In the diagram below, I have multiple service offerings, one per country, I want to use the same catalog item, Request Access, in this case it woul be for JDE ERP, but I also want to use it for say SAP. I might be confusing concepts here between Catalog items (Request) and orderable items.
Thanks in advance
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @sylvainbarr ,
The short answer is: Yes, absolutely. Not only is it possible, but it is also the CSDM Best Practice to prevent "Catalog Sprawl" (having hundreds of duplicate items).
You are looking for a "1-to-Many" consumption model. A single Catalog Item (e.g., "Request Access") can serve as the front door for multiple Service Offerings (JDE Canada, JDE USA, SAP, etc.).
How to implement this (The Dynamic Approach):
Instead of hardcoding the Catalog Item to a single Service Offering field on the definition form, you make the selection dynamic during the request.
1. The Catalog Item Setup Create a generic item named "Request Application Access".
Add a Variable: Create a variable (Type: Reference) pointing to the Service Offering table (service_offering) or your Business Application table.
Filter it: Apply a Reference Qualifier so it only shows the relevant offerings (e.g., Class is Service Offering AND Parent Service is ERP).
User Experience: The user opens "Request Access" and selects "JDE ERP - Canada" from the dropdown.
2. The Fulfillment Logic (Connecting the Dots) This is the most important part for CSDM reporting. Since the Item is generic, the RITM doesn't inherently know which Offering gets the credit.
In Flow Designer: Add an action at the start of your flow to Update Record (The Trigger RITM).
Set Field: Set the RITM's Service Offering field TO the value selected in the Variables.Service_Offering.
3. The Result
User: Sees one clean form.
You: Maintain only one Workflow/Form.
Reporting: If a user selects "JDE Canada", the RITM is tagged with JDE Canada. If they select "SAP", it is tagged with SAP. Your dashboards for "Consumption per Offering" remain accurate.
Diagram Context: Looking at your diagram, the "Catalog" box (Green area) sits distinct from the Offerings. This visually confirms that the Catalog Item is a reusable object that can be linked dynamically to any of the Red boxes (Offerings) via the user's selection.
If this response helps clarify the architecture, please mark it as Accepted Solution.
This helps the community grow and assists others in finding valid answers faster.
Best regards,
Brandão.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @sylvainbarr ,
The short answer is: Yes, absolutely. Not only is it possible, but it is also the CSDM Best Practice to prevent "Catalog Sprawl" (having hundreds of duplicate items).
You are looking for a "1-to-Many" consumption model. A single Catalog Item (e.g., "Request Access") can serve as the front door for multiple Service Offerings (JDE Canada, JDE USA, SAP, etc.).
How to implement this (The Dynamic Approach):
Instead of hardcoding the Catalog Item to a single Service Offering field on the definition form, you make the selection dynamic during the request.
1. The Catalog Item Setup Create a generic item named "Request Application Access".
Add a Variable: Create a variable (Type: Reference) pointing to the Service Offering table (service_offering) or your Business Application table.
Filter it: Apply a Reference Qualifier so it only shows the relevant offerings (e.g., Class is Service Offering AND Parent Service is ERP).
User Experience: The user opens "Request Access" and selects "JDE ERP - Canada" from the dropdown.
2. The Fulfillment Logic (Connecting the Dots) This is the most important part for CSDM reporting. Since the Item is generic, the RITM doesn't inherently know which Offering gets the credit.
In Flow Designer: Add an action at the start of your flow to Update Record (The Trigger RITM).
Set Field: Set the RITM's Service Offering field TO the value selected in the Variables.Service_Offering.
3. The Result
User: Sees one clean form.
You: Maintain only one Workflow/Form.
Reporting: If a user selects "JDE Canada", the RITM is tagged with JDE Canada. If they select "SAP", it is tagged with SAP. Your dashboards for "Consumption per Offering" remain accurate.
Diagram Context: Looking at your diagram, the "Catalog" box (Green area) sits distinct from the Offerings. This visually confirms that the Catalog Item is a reusable object that can be linked dynamically to any of the Red boxes (Offerings) via the user's selection.
If this response helps clarify the architecture, please mark it as Accepted Solution.
This helps the community grow and assists others in finding valid answers faster.
Best regards,
Brandão.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @Itallo Brandão ,
This is as wrong an answer as it can be. Why do you think that a catalog item can only be associated with one service offering if you look at an OOTB configuration? In general, there is a 1-N relationship meaning, a Sevice offering can be connected to many catalog items, but a catalog item can only be associated to one service offering.
You state "Not only is it possible, but it is also the CSDM Best Practice to prevent "Catalog Sprawl"" - Where is the documentation for this? Please provide a link. Or is the text written just generated by AI non-sense?
If my answer has helped with your question, please mark my answer as the accepted solution and give a thumbs up.
Best regards
Anders
Rising star 2024
MVP 2025
linkedIn: https://www.linkedin.com/in/andersskovbjerg/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
As per my understanding and knowledge in servicenow standard data model a catalog item is designed to be associated with a single service offering.......meaning you normally link one catalog item to one offering to get clean reporting and ownership......so you can’t directly reuse the exact same catalog item across multiple offerings out of box.....if you need that behaviour you usually either create separate catalog items for each offering or build custom logic/fields and flows to simulate a many to many relation because the oob association doesn’t support one catalog item being tied to several service offerings at the same time......
If you found my response helpful, please mark it as ‘Accept as Solution’ and ‘Helpful’. This helps other community members find the right answer more easily and supports the community.
Kaushal Kumar Jha - ServiceNow Technical Consultant/Developer
