Separate catalog items or unique catalog item for different operations related to a common topic

[Fred Jean]

Hello,

Let's take a use case (or actually a set of use cases) where users should be able to request different operations related to a given item. Let's say for instance operations such as installing, moving or disposing a server. 
Knowing that these uses cases would involve some common variables but also a number of different variables depending on the operation, and that the actual process would also be different (involving different tasks),

I consider that the best way to address this is to have one catalog item for each operation.

From the user perspective :

• Given that these operations should be requested through the portal, and that the portal encourages the use of the search field, if the user types "install a new server" he would end up on the relevant from without having to specify again the intended operation is installation
• Having a dedicated form avoids that behaviour hiding and showing variables when selecting the operation. This behaviour, changing the form layout,  can be seen as annoying/disturbing.

Form the developer perspective :

• Simple separate forms are easier the implement and maintain than a more complex common form involving conditions to show/hide variables and may be make some mandatory or not, read only or editable.
• Catalog Builder with templates and variables set makes it easy to create similar, yet different catalog items, even making possible to define different approvals and tasks without having to implement a flow.

However :

• some customers still insist on having a common catalog item for such use cases
• the ServiceNow Best Practice document "Design a world-class service catalog" states : "Should we create separate catalog items for the possible options within a request? Avoid
  creating multiple similar catalog items. Instead, build flexibility within the catalog item to allow
  users to pick between multiple options (such as different laptop configurations) within the
  request form. Use Service Catalog variable question choices to develop that flexibility."

I am not sure the ServiceNow Best Practice was written with the same use case in mind, but I'd be curious to know :

• What could be the arguments for that ServiceNow Best practice statement ?
• What's the opinion of Experts, users and customers on this topic (single common item or separate ones) ?

Thanks for your feedback.

[Brad Bowman]

Ultimately, as developer's and architects we can advise and guide, but if the customer insists on one or multiple items, then that's what we deliver.  In your server example, I would create 2-3 Catalog Items (install and move in the same item?) potentially utilizing a common variable set as a starting point if there are a number of shared variables.  When there get to be more than a couple unique Catalog Tasks, approvals, or other action steps for a process, it's often best to have that in it's own workflow/flow, but you can do the same with a subflow called from the main flow for each type.  The ServiceNow documentation example you cited would have extremely similar variables and process steps, when ordering the same laptop model with different amounts of RAM, storage, etc. so in that case one Catalog Item would be best.

[AndersBGS]

Hi @Fred Jean ,

Besides what @Brad Bowman  already have highlighted (I do agree with his approach), then also think about relating the catalog item(s) to service and service offering. There should be a 1:n connection between catalog item : Service Offering... If you have that in mind, is the catalog item(s) that you mentioned related to one or several service offering?