Categorizing Incidents for various IT groups

[Michael Domke]

There are many different IT groups in my company that manage and support their own "stuff". Regardless of what that "stuff" is, when there's an issue, an Incident is created and assigned to the appropriate group.

Out of the box functionality for Incidents within ServiceNow works for a generalized environment and we've actually customized our instance further to be a little more granular in how Incidents are "categorized". That is, what data we collect to document the Incident.

The issue we're having right now is that several of these groups are becoming more familiar with what ServiceNow can do in terms of customization and they are now requesting very specific needs in terms of categorizing their Incidents. Specific fields with specific choice values, etc. These needs are specific enough that they really can't be shared among other groups.

What I'm afraid of is that we'll need to manage a whole sub-set of different ways to categorize Incidents for many different groups. For example, one group wants a certain choice list of categories and other field types and other groups want something unique to their "stuff". This could get messy.

My question to the community is to find out what others may have done to manage this varying type of Incident categorization.

Thanks for any input,

Michael

[danielbilling]

that's true Maros.

you need to create a similar reference field

[Dan Tolgyesi1]

Hi,

My company has a similar setup. There are basicaly 2 main incident splits that I need to work with. We have "IT Incidents" for your usual IT issues - Hardware, application, server etc etc, and we have "Business Incidents" which are all the data issues (we have a bespoke in house application the administer policies) and we log these issues separately with different SLA's and workflows.

What I did was created 2 new tables that extended the out of the box "Incident" table, 1 called "IT Incident" and the other "Business Incident". This meant that I could report of the incident table as a whole, and split them up where required when key stake holders needed specifics about IT Incidents and Business Incident counts.

This also meant that I could customise each table to suit their needs such as having separate categories/subcategoreis/priorities/SLA's etc,   but still sharing the key fields to help with reporting, the prefix is still the same for both (This could be changed but the business did not want this).

They are also logged in a completely separate way, IT Incidents are logged through the IT Service Desk and business incidents are self logged via the IT Portal with templated forms.

Also, there are seoarate needs within the IT Incident, but not as vast as the IT/Business incident split, so I controlled this by creating different views for different teams and all of this seems to work well for the business.

Hope this helps, let me know if there is anything else you think I could answer.

Thanks,

Dan

[Michael Domke]

Thanks for the reply Dan,

Your solution is one I thought of way back when these groups started feeding me with all their unique requirements. Unfortunately, it's not one we're willing to do. Building a different table and making it unique for certain groups might be as much of a headache as modifying the Incident form to suit their needs.

Thanks,

Michael

[naveedkh]

Please find attached the category for Incident Management.

[Renee5]

Naveedkh -     You have "departments" separated on your list of categories, and I have a few questions around thatI

1.   Is "Department" a seperate drop down on your incident form?
2. Are those categories depending on the department that chosen (or signed in?)

3. Can the accounting department see the IT department incidents and vice versa if needed?

We're struggling with having 1 incident form and different departments having different fields/categories/and options that they want to see, and like the OP, I'm trying to figure out the best solution.

Thanks!