Clarify table elements: incident_state vs state; active

tayrez · ‎06-27-2015

Hello,

What is the difference between incident_state and state on the Incident table? How are they used (out of box)? What is their relationship?

Active Field (not specifically the incident table): What is it used for? What sets the switch? Where I can I learn more about it?

Thanks,

Therese

bernyalvarado · ‎06-27-2015

Hi Therese,

You're welcome!

As for the other question, the active state in the task table is managed primarily by a business rule which is called Task Active State Management. That business rule will set the active state in accordance to whether the state of the task is an "inactive type of state". That definition of an inactive state can be found in the script include TaskStateUtil which specifies the states 3, 4 and 7 as inactive states.

On a similar way, there's a lot of business rules that actually set the active flag to false, but from what i know, OOB there's consistency in setting respective state values that represent an inactive item. (You can see these by searching in business rules and other server/client scripts for where the script field contains .active = false)

In your case, i believe you could have some customizations (or users) that perhaps are directly setting the active flag to false without setting the respective state to an inactive type of state.

I hope this is helpful!

Thanks,

Berny

View solution in original post

tayrez · ‎06-27-2015

Hello,

Thank for replying. I understand that Incident in an extension of Task and that state originates on the Task table. I don't understand why SN added incident_state to the Incident table if state was already available.

I also know that Active is a boolean field. and that indicates that record is closed. By the way the Active state is True when an incident is in the Resolved state:

Therese

mitzaka · ‎07-30-2015

I believe the idea was to be flexible back in time with SNOW. In past releases of ServiceNow, if a choice list was on task, then incident, problem, change, etc. all shared it (like they do any field on task). The limitation back then being that incident and problem couldn't have different choices for that field. If you wanted incidents to have an available state of "awaiting user info", it had to be added to all task tables, which didn't necessarily make sense for changes or problems. So the incident table got its own separate choice list field for its specific states (incident_state), and by default the task.state field was just not used for that table. Flash forward to today, and extended tables can have their own unique choices for a choice list field on the base table.

I think this is some legacy thing, which just needs to be cleaned up.

ctrusty · ‎08-21-2015

I'm not sure a clear cut answer has ever been provided on this question. However, I agree with Dimitar here in that the field incident_state was introduced at some point to fix a legacy problem and is technically no longer needed. However, ServiceNow couldn't deprecate it because if they did, it would affect millions of tickets throughout various clients that utilized the field during that time.

Therefore, their best solution was to keep both fields, use the State field on the Incident form moving forward (as of the Fuji release), hide the incident_state field, and use business rules to keep them always in-sync. That way if either field is used on the form, in a script, etc. then the sync from the business rules would allow all scripts to still work (regardless of which field is used).

Since it is on the form by default in Fuji, it is my understanding State should be used. However, it is worth noting there are issues in reporting (that I'm not quite clear on) where certain values from the choice list don't show up. For example, if Incident/Problem/Change all have a choice with a value of 8, but all three have different labels, it might only show one of those 3 labels in the drop-down. I'm not clear on this but it is something to keep in mind. This might be where the incident state field can come into play for reporting.

tayrez · ‎08-21-2015

Thank you! This is very interesting and helpful information.

Therese

mitzaka · ‎08-24-2015

As for the different values of the state where multiple labels are in place, I have come for the conclusion that for all things which extend the Task table, it's always good to have a dictionary override of the state field. This way it's all sorted out and clear who is who:)