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

[tillu]

Hi all,

Sorry for my late input but we had the very same situation, or similar.

Basically we implemented a different value for states across the child tables, meaning that from the task table, trying to filter down tasks for a given state was impossible. Ideally for us it would have been to implement it using the same state value for all child tables, for example 2 for Work in Progress for all the record types. However the state in the filter would still give the user multiple Work in Progress states to select.

Anyway, with the mixture of states filtering task records was impossible since the real state of the child record was in the child table. What we did is added another choice field in the task table   with all the states being used. A new table has been created which maps all the states being used by the child records to the new choice field. For example, WIP in incidents is 2 and WIP in service request is 3. Incident state 2 would map to 2 and Service Request state 3 would map to 2, thus getting a common value for WIP. Now, a business rule has been created on the task table which fires when the state of the task changes. The BR calls a script include which looks up the corresponding mapped value and sets the new choice field to that value. Furthermore, another business rule has been added which fires when the value of the new choice field is changed, updating the task state field to the corresponding value. This enabled the users to filter all the tasks that are in a particular state independent of the type of record, i.e give me anything that is in WIP.

Using a calculated field (not recommended):

Another option I was considering was to add a calculated field in the task table which gets the state from the child record. However this method could be very expensive in terms of performance. Consider the amount of processing that is done if you have a considerable amount of task records. Also, a calculated field will recalculate every time the user sorts or filters the task list. Also, if the task list is inserted in a widget and set to refresh every 5 minutes one could imagine the performance issues this might cause. Although the calculated field would be used as a view, it could be very expensive.