How to maintain multiple categories and sub-categories in incident form

Saridha_L1 · ‎08-23-2020

Hi Team,

We have 20+ Categories ,and many sub categories in Incident form. Could you please help, how to achieve this.

Regards,

Saridha.L

Giles Lewis · ‎08-23-2020

I have found that the out-of-box Category/Subcategory scheme often does not work very well in large organizations because you can have lots of stakeholders with different reporting requirements, and it can be impossible to get everyone to agree on a global scheme.

We abandoned the OOB Incident Category/Subcategory fields, and replaced them with a custom reference field. We called the new field "Operational Category". (You can call it anything you want.) You can restrict the custom field by Assignment Group or Business Service. We chose to restrict it based on Business Service.

We use Business Service as our primary means of categorizing Incidents. We have about 500 Business Services. Operational Categories are either global or not, based on a check-box. There are a very small number of global categories. In order to be global, a category must make sense for any Business Service. The hundreds of categories which are not global must be associated with one or more Business Services. A non-global category can be valid for multiple Business Services. There is an M2M table that tracks which categories are valid for which services. When you try to select the category for an Incident, the reference qualifier limits you to categories which are either global, or are valid for that service.

The nice thing about this model is that it is scalable. You can have hundreds or even thousands of Incident categories without the system becoming unmanageable. Once you select a Business Service (which is required), you are restricted to a very short list of possible categories. We add new categories all the time without thinking about it. If you add a new category that can be used for three Business Services, you can have confidence that it will not affect the other 497 Business Services. If you are not using Business Services with your Incidents but you are using Assignment Groups, then you could do the same thing with Assignment Groups.

This is definitely a customization and a deviation from the out-of-box, so I am not necessarily recommending it. It is just something to consider if you are struggling to meet your reporting requirements using the out-of-box Incident categorization scheme.

View solution in original post

Giles Lewis · ‎08-23-2020

I have found that the out-of-box Category/Subcategory scheme often does not work very well in large organizations because you can have lots of stakeholders with different reporting requirements, and it can be impossible to get everyone to agree on a global scheme.

We abandoned the OOB Incident Category/Subcategory fields, and replaced them with a custom reference field. We called the new field "Operational Category". (You can call it anything you want.) You can restrict the custom field by Assignment Group or Business Service. We chose to restrict it based on Business Service.

We use Business Service as our primary means of categorizing Incidents. We have about 500 Business Services. Operational Categories are either global or not, based on a check-box. There are a very small number of global categories. In order to be global, a category must make sense for any Business Service. The hundreds of categories which are not global must be associated with one or more Business Services. A non-global category can be valid for multiple Business Services. There is an M2M table that tracks which categories are valid for which services. When you try to select the category for an Incident, the reference qualifier limits you to categories which are either global, or are valid for that service.

The nice thing about this model is that it is scalable. You can have hundreds or even thousands of Incident categories without the system becoming unmanageable. Once you select a Business Service (which is required), you are restricted to a very short list of possible categories. We add new categories all the time without thinking about it. If you add a new category that can be used for three Business Services, you can have confidence that it will not affect the other 497 Business Services. If you are not using Business Services with your Incidents but you are using Assignment Groups, then you could do the same thing with Assignment Groups.

This is definitely a customization and a deviation from the out-of-box, so I am not necessarily recommending it. It is just something to consider if you are struggling to meet your reporting requirements using the out-of-box Incident categorization scheme.

Giles Lewis · ‎09-18-2020

Consider voting for this enhancement:

https://community.servicenow.com/community?id=view_idea&sysparm_idea_id=21f2de95db9a90d0a08a1ea668961929&sysparm_idea_table=x_snc_com_ideation_idea&sysparm_module_id=enhancement_requests

Philippe Lamber · ‎01-24-2022

Unfortunately, your idea has been dismissed.. It seems that it does not occur to SN application architects that fields of such importance, as far as reporting goes, should not be implemented as string column but rather as reference. Adding custom tables not only customizes the data model but increases the license fees as well, thus making the solution out of reach for some organizations.