Idea Details

Catalog and SD should share same request module/ID

Last activity 05-31-2019 01:44 AM
Anon Anon's profile image
09-15-2014 04:14 PM

Today, whenever any ticket gets created in catalog we need to create their corresponding request ticket in SD through PAM. By doing this users get confused between catalog request id and SD request ID.


We request CA to come up with the solution where these two products share the whole request module or at least the request ID. It would be good if both product share the whole request module so that we dont need to create SD request ticket for each and every catalog request.





04-14-2017 08:44 AM

Great to see this has been under review state atleast.

02-06-2017 04:02 PM

This idea is being Wish-Listed for potential inclusion in a future release.


Before this idea moves to the next stage (Currently Planned or Not Planned), I would like to invite community members to please provide additional input and/or vote. Please note that Wish-listed ideas are selected for inclusion in a release based on multiple factors including - number of votes from community members, alignment of idea with a release's themes and goals, complexities and risks involved in implementing the idea, so a timeframe for availability of the idea as a product feature/functionality cannot be provided. Additionally, the implementation of your idea may not be exactly as requested and/or may be delivered in a new user experience. 

05-13-2016 04:57 AM

Great thought!


Reducing the confusion and work load would anytime get the clients satisfaction. there is no additional value to catalog request, if you are linked to SDM and creating the ticket in from Catalog via PAM. If this is can be consolidated then that great benefits in customers view.

05-13-2016 02:37 AM

This will require very careful thought. Will the shared module also include change orders on SDM as many services on catalog could result in change orders

03-11-2016 07:42 AM

knowing that SDM and SC are now part of the same Service Management I would like to see it as a single product vs 2 separate components and install.

Will eliminate the need of the above


11-19-2015 05:40 AM

Great idea. Although there will be a problem when we have a cart created in the catalogue since that cart will create more than 1 ticket in the SDM - so all tickets related to the cart in SDM can't have the same request number. There needs to be some kind of prefix or something that states which catalogue ticket the SDM ticket belongs to.

08-04-2015 12:01 PM

Another great idea. You has my vote.

08-04-2015 10:52 AM

great idea

03-13-2015 08:43 AM

If you have an integration where Service Catalog is your self-service end user interface to submit requests that eventually are acted upon by support analysts, then once the SD ticket is generated, the Service Catalog request becomes obsolete and only exists as a reference (confusing as such) for the end user.


What's needed is tighter integration between catalog and ServiceDesk whereby Service Catalog doesn't "serve back" an identifier until the request has been created in ServiceDesk. Then, the only identifier the end user sees is the ServiceDesk request numer which they reference when requesting updates. Also, the other necessary part that needs to be in place is a method to see status and make queries into the ticket from the existing Service Catalog interface.


Again, the 2 products need to be more tightly coupled when SC is the self-service user front end.

03-10-2015 02:33 AM

Moving this idea to review.


Community Members - please add more specifics to solidify the idea, and vote to help CA determine right priority for this idea.

09-19-2014 03:26 AM

Great idea that we've been thinking about over here as well since long. Not having a common request module is troublesome. As you stated end users will call into the service desk to request updates to their tickets and provide a Catalog request number, analysts using Service Desk need to search for SDM requests first, then try the catalog request number field (we have a custom field for this).


But it goes further than this: Service Catalog and Service Desk each send out distinctly different notifications, Service Desk offers survey functionality and Catalog does not, there is some basic exchange of log comments and notes now (or at least we built that ourselves already), status updates do not flow through properly, etc etc.


I've been thinking that CA could maybe add an option to Service Desk, something like "Use Catalog requests in the SDM request module", so that the OOTB SDM requests would then basically look at the usm_request table instead of call_req. With the addition of an object to usm_request in service desk this should be easy enough to establish. CA could then consider to also offer some other functionality available in the current call_req: logging comments on Catalog requests directly from service desk without the need for PAM processes to copy over ntes and comments, same for attachments, why not even workflow? I cannot stress the importance of a functionality like this, as in real-life users also have the ability to call the service desk directly or send in an email to request something. These calls/mails would always end up in Service Desk, but if these are actual requests then there is currently no way to "convert" these into actual Catalog requests besides manually completing a request form in Catalog (which again creates a different ticket confusing the end user even more).


See also my (old) post on SDM-Catalog touchpoints: SC - SDM touchpoints (related to quarterly Service Management meeting)


+1 !