State field on Task Table

[Scott_Lathlean]

Hey All,

Historically, our instance has used the Incident_state and Problem_state fields for those to task types, but I'm trying to move towards using the State field on the Task table. This is all fine, but we are trying to report on the state field on the Task table and we are finding that not all labels are visible. I understand this is due to many different states having the same 'value' on the task.state field.

Is this bad practice to have multiple choices options on the task.choice list with the same value, but different labels? I've only really experienced an issue when reporting visually on the Task table and trying to filter based on State, so is it better to visually report on the individual task types? Or am I missing some setting where ServiceNow is smart enough to read the task type and apply the proper state from the child table?

Thanks

- Scott

[Kristian Johns3]

Sorry to be so late on this, but we've had this issue from the beginning. In my opinion it IS bad practice to use same values for task states that have different labels. There are plenty of task types with states that are at least very similar or exactly the same, so using the same values there are understandable, but it makes no sense to have, say, an incident state value of '4' mean incidents which are "Awaiting User Info" and to have the same value for Problems and Tasks mean records that are 'Closed Complete' or 'Closed Incomplete', respectively. Granted, the primary purpose of the state field isn't for reporting, but rather to facilitate workflows, but this is an issue that I can only imagine most customers run into. My theory is that ServiceNow probably made this poor design decision very early in the SNow development process, and now it would be very difficult to fix the issue automatically during upgrades (since the state field is so integral and far reaching through the environment), so it is left alone.

My resolution to this was to add a separate column in the task table called 'u_state_label' that is labelled 'State' (so that there are two columns in the task table labelled 'State'). I created business rules against the task table that look up the appropriate label for any task type whenever the task state is changed, so that the correct label is copied into the u_state_label field. Then reports against the task table, or reports against any database view that combines task children tables, can use the 'u_state_label' field instead of the 'state' field. The reports would look exactly the same, with the exception that the display state of the records would be accurate.

[poyntzj]

We did the same as Kristian

It does sometimes miss, but not too often

the hardest part is then getting the users who want to report off the task table to remember to use the "State_text" field and not the "state" field.

[Hernan3]

Thank you for sharing, this is something we are currently considering.

Have you ran into any issues after updating/upgrading your production instance?

[Dawid2]

Hi Kristian,

Since I ran into exactly same issue as described here, would you mind sharing the Busienss Rule that you created to work-around this issue? It would be much appreciated.

And sorry for digging such old post!

[poyntzj]

create your new field on the task table

on each table you simply create a BR that copies the dispalyvalue of the state field to your field above