Currently Request Center (SRC) only allows 1 Service in the catalog to point to a given underlying implementation Project. There are valid cases where more than one service may indeed need to submit ...into the same Project given fields/form/workflow/fulfillers. The entired idea behind SRC was to allow a different organization/presentation to the end user based upon how a catalog should logically look by decoupling that from the underlying implementation details of the Project Hierarchy. This is a very valuable concept. However why not take it further. There are numerous cases where more than one logical entry point into the same Project could be very beneficial. In certain cases it would greatly reduce the complexity and number of underlying Projects which may need to be implemented and maintained given the current restriction.
1) Consider cases where the Catalog may be large and complex in terms of categories. There may even be overlap or ambiguity in how end users may choose the initial category such that listing the same exact Service entry point in two different areas could be beneficial.
2) Alternatively there could be numerous different logically named Services which all need to go to the same Project. For instance think of the simple case where you may have numerous applications built within Serena. You could have one Serena Support project in SR to receive such requests. However for an end user requesting access to App A or App B or App C you could essentially have a distinct appropriately named service for each which all end up in the same Serena Support project which would have the same fulfillment team.
3) Furthermore, being able to choose different submit forms seems to lend to this idea of reusing the same project but to provide slightly different submit forms or default text based upon the Service requested.