Managing categories between assignment groups

robert_price · ‎04-02-2015

We have a lot of groups in our IT department. Some of them have their own requirements for tickets, and some of them don't; some of our groups use the category/subcategory stack (using the dropdown category field), and some of them don't. However, all groups want to be able to transfer tickets between each other, and have those tickets retain the previous categories so they don't have to change said categories when they arrive (especially if they are going to be sent back afterwards).

In addition, our management wants to be able to make reports on ticket content based on the category field.

We've solved this issue with a complicated (and admittedly buggy) script, and a few extra category fields (specific to certain groups) when the group in question isn't going to be on the same reports as the others. However, I'm curious about how other companies handle this issue. Does anyone else have to worry about retaining categories between departments with category systems of their own? What's the bet way to handle this kind of thing?

de_dah · ‎04-06-2015

Our organization went through a few iterations, but in the end went with something fairly simple. There's a lot of data you can get out of a system, but the more complex your categorization is, the less likely staff are to properly categorize their tickets anyway. We decided to get into generalizations. Applications, Hardware, Security, Services, Network, Storage, Servers, etc. Under the first level, we've got some categorization that stays fairly generic, but in some cases, we get specific as well, depending on the needs of the IT groups and the mgmt. teams. We use UI sparingly and it only comes out to play with a few of our app support teams. Some of our categorization can be overlapped a bit, but when it comes down to reporting, we get some great data out of our structure. Our rule of thumb is that we can re-assign and re-categorize as often as needed, but the true categorization is what the ticket is closed with, as often you don't know what the real issue is until you've dug into it.

We also asked this question often - what kind of reporting do you want to get out of the system? Often, that drove the discussion of what was really needed for categories.

View solution in original post

BenPhillipsSNC · ‎04-06-2015

Hi Robert,

What you're describing sounds like it should be easily addressed by UI Policies and views. Different groups can have different views, some views contain certain category drop-downs and others might exclude it. Likewise, certain form elements could be made visible or hidden, or active/deactivated, based on some logic such as what group they are in. You'd insert that logic into the "UI Policy Action" on the related UI Policy.

robert_price · ‎04-06-2015

UI Policies and Views are actually part of how we've handled the issue thusfar (though, of note, Views and the Global Search Box don't mix well, so I've had to construct a search view and a complicated series of view rules as a result). UI Policies are great for handling separate category fields.

However... our management isn't fond of having separate category fields for different groups. They would prefer a single category field, as that makes it easier to generate overall reports on groups that share duties. In addition, separate category fields mean that some category fields will be, by default, left blank; management doesn't like seeing blank spots on their report, and would prefer that the main category field list the name of the assignment group involved in the ticket whenever the ticket is assigned to a group that uses its own category field. This only complicates matters.

BenPhillipsSNC · ‎04-06-2015

Ok.. I think I see what you're saying..

I think I would agree with them too, I would rather go for ONE category field. You can have lots of choices in it's choice list, and you can deactivate certain choices for certain users or roles or states of the ticket. You might want to consider adding and removing options with a client script, as shown here:

GlideForm (g form) - ServiceNow Wiki

6 Change Choice List

Method Summary
Return Value	Details
void	addOption(`fieldName, choiceValue, choiceLabel, [choiceIndex]`) Adds a choice to a choice list field. If the index is not specified, the choice is added to the end of the list. Optional: Use the index field to specify a particular place in the list.
void	clearOptions(`fieldName`) Removes all options from a choice list.
void	removeOption(`fieldName, choiceValue`) Removes a specific option from a choice list.

BenPhillipsSNC · ‎04-06-2015

Same thing but with examples:

Change Choice List Methods