Best Practices for a Single Catalog Item That Creates Incidents and Enhancement Requests

[JackVT]

Hi everyone,

We currently have two Employee Center buttons:

• Something’s Broken -> generic Incident form

• Request Something -> general Service Catalog

Background:
I’ve been approached by multiple internal IT teams—each managing a specific application—asking for a streamlined way to let their users:

1. Report app failures (Incidents)

2. Request new features (Enhancements)

Many of these teams also want their app(Azure Dev Ops, SmartSheet, PriceFx, etc) to integrate with ServiceNow (especially if a plugin already exists).

Here’s what I’ve sketched so far:

1. One catalog item (“Application Support Hub”) with two top-level variables:

   • Request Type (Incident vs. Enhancement)

   • Application (App A, App B, App C, …)

2. Variable Sets for each (Application × Request Type) combo, shown/hidden via UI Policies or a Client Script

3. A Flow Designer flow that reads those two variables to assign to the right team, set SLAs, notifications, approvals, etc.

4. Leave our existing “Something’s Broken” and “Request Something” tiles intact, and simply add or nest a link to this new form.

Questions:

1. Is a single catalog item with variable sets for each app-type combination a sensible approach, or should I create separate items (e.g. “App A Incident,” “App A Enhancement,” etc.)?

2. Given we already have a generic Incident form, is it better to route app incidents through that with an “Application” field, or give app incidents their own form?

3. Any other ideas/concerns I should think about.

Thank you!

[Community Alums · Accepted solution]

hi @JackVT ,

You're aiming to streamline how different internal IT teams allow users to report issues or request features for their respective applications. Instead of creating multiple catalog items for each application and request type combination, your idea of a single “Application Support Hub” catalog item is a smart and scalable solution. In this unified item, users can first select the Request Type (e.g., Incident or Enhancement) and then choose the Application (e.g., Azure DevOps, SmartSheet, etc.). Based on these selections, you can dynamically show the appropriate fields or variable sets using UI Policies or Client Scripts. This approach keeps the catalog clean, improves user experience, and is much easier to maintain in the long run.

As for routing incidents or enhancements, it’s better to let the unified catalog item create and categorize the records directly through Flow Designer. You should avoid redirecting users to the generic “Incident” form. Instead, your flow should intelligently detect if the user submitted an Incident or Enhancement and then create the corresponding record in the appropriate table (such as incident for failures or a custom table for enhancements). This allows more flexibility in SLAs, assignment, approvals, and notifications while maintaining data integrity and consistent reporting. By routing requests in the backend, users don’t have to deal with multiple forms or paths.

When it comes to integration with external tools like Azure DevOps or SmartSheet, your flow can also conditionally trigger different actions based on the application selected. You can utilize IntegrationHub spokes or REST APIs, depending on what integration methods are available for each system. Finally, on the Employee Center, you can add a new tile like “Application Support Hub” so users can easily access the new unified form without disturbing the current “Something’s Broken” or “Request Something” tiles. This approach ensures smooth navigation while giving each app team a more structured and efficient process for handling requests

[JackVT]

Thank you for the tips and guidance!