Application Specific Fields on Incident Table

IndianaJones
Tera Expert

We are struggling with customizing the Incident table to include application specific fields. This obviously doesn't scale well when you consider the many applications a company may have. So my question is, how do teams capture relevant data for an application when an Incident is created? 

 

Example: We are having issues with our call system and they are wanting to capture data for each user. The data would be headset type, location when the issue occurred, was the call dropped, how long was the call before an issues occurred, and a couple of other things. We thought about creating them a template to use, but reporting on the template isn't nearly as powerful as dedicated fields. We thought about building a catalog request to capture all of this information for a user but that seems weird since catalog items arent really issue related. How are your teams tackling this today?

6 REPLIES 6

Hemanth M1
Giga Sage
Giga Sage

Hi @IndianaJones ,

 

Have you tried using category and subcategory?
Ex:
Category - Call systems
Subcategory - Headset type


Maybe add another field to capture additional details about the issue - generic field

You can report on category and subcategory, and then drill down to look at details for each subcategory. (Make use of CI here)

You can keep adding categories and subcategories as and when needed.
You can’t capture every detail as fields just for reporting!

 

 

 

 

Accept and hit Helpful if it helps.

Thank you,
Hemanth
Certified Technical Architect (CTA), ServiceNow MVP 2024, 2025

Hi @Hemanth M1 

 

"You can’t capture every detail as fields just for reporting!" - I strongly agree. I think the issue is communicating to stakeholders where to draw on the line on when a field is worth putting on the table and when it is not. In the past we have gone the category/sub category route but then end up with a very massive list here as well. So maybe the better question is how do teams get enough detail in their Incidents that allow for robust reporting without overloading the table fields?  

 

 

 

 

Hi @IndianaJones ,

 

Can you tell us what kind of robust reporting you’re expecting? Could you provide an example?

Accept and hit Helpful if it helps.

Thank you,
Hemanth
Certified Technical Architect (CTA), ServiceNow MVP 2024, 2025

@Hemanth M1 


A lot of it is investigating the root causes of a problem record. An example is there's a widespread issue and its going to take investigating the tracking of 15-30 incidents to see if there is a underlying issue between all of them. In this example we are trying to figure out if there's an issue with our phone system or the headsets we are using with our phone system. The data we are trying to collect is the type of headset the person is wearing, their location when they experienced an issue, did the call drop or was the call quality poor, and the time of day when it happened.  That would require these incidents to have fields that we can report on and are very specific to this one problem. And once the problem is solved, these fields wouldn't be needed anymore which creates tech debt if they were put on the Incident table.