Is it fine to customize OOTB Incident state values? If so what is the best way to customize?

[Suggy]

We want to deactivate few OOTB state values and add new values. I see that there are many script includes like

IncidentStateSNC

IncidentState

IncidentSNC

One of my colleague told not to customize state values for Incident as many scripts and functionalities will be impacted.

Is it true?

If not, can we customize? If so , are there any specific things to look at in order to customize?

[bammar]

Ok so - one has to be careful on State updates on Task table fields.

You CAN do anything but there are alot of connected parts that need to be audited first.

A. when you remove a state or rename a state - is the state referenced on a Business rule condition? or an assignment condition, is the state referenced by its display name or the ANNOYING numbers on the back end  like 6 for closed think that you can never remember

I would argue with folks especially on Incident that these values are ITIL values kind of like how we call a ticket an incident in itil and we have requests seperate.

Now - TASK has states- alll Task tables auto inherit those states- Each lower level table like incident can have additonal states - You can add states just to incident that wont show in other tables...

ALso you have to go to dictionary and study dictionary overrides for states..

This means on a certain table for state- you can say states 6 and 7 are closed states as well as your new states 55- this means sys will mark those records active false- you can also set other default values...

If you dont need the headache avoid it- however doing things granularly is safe and if you have the knowledge you can do whatever you want. So i would start with a table that has a Dictionary override for state- study and build on that- then audit all Business rules, assignment rules and client scripts on that table to ensure what you want will happen.

Once you do this for a few years you build on the other due diligence so its simple but i had my own growing pains with this - where i did something on one table and it messed up others and I learned from it. 

[Suggy]

Thank you @bammar for your inputs.