Logic of states values on task tables

[david_legrand]

Hi,

This is a question I asked myself for a long time on a theoretical point of view but now I might have a real case:

One of my customer is starting to have a lot of processes in place and I would like:

1) To provide the "operators" a common list with all the tasks to perform

2) To provide the "managers", a global overview of the tasks to perform

We all know that all the processes are in fact "tables child of task" so using the "task" table as a base for the lists and for the reports will make sense.

Of course the states labels won't always be the ones we have on the process but as long as they are "consistent", I think we can live with it.

But, even in ServiceNow vanilla, the states are sometimes weird. For example, the "Closed Complete" state will be seen as "Awaiting Problem" on incident table and as "Pending Change" on problem table.

Figure 1 : Extract of Fuji vanilla states for Task, Incident and Problem

And when I do a quick report on a Developer vanilla instance, I would see this if I try to report on the "Closed Complete" tasks.

Figure 2: Report to show the "Closed Complete" tasks (including not closed incidents and problems)

And of course, the issue if we try to align the states across the processes, we'll break all scripts and rules in place using the states and we'll have to update all existing records.

Dis you already face this issue? Do you know a good reason why the states are made that way?

I don't see how ServiceNow could fix that properly even if it would be great to use more and more ServiceNow as the "User Interface for ESM processes". We can always make a script and a temporary application based on the logic of Packages Call Removal Tool (made for Calgary release), but the work for ServiceNow, the performance impact during the transformation (specially in the large companies) and the work for the admins will be too important to make it viable.

Bonus: One of the weirdest vanilla application regarding these states is the PPM application so far

Draft is -6 or -5 or 1, Rejected is 7 or 3 (and 3 is usually a "Close complete"), so we can't make proper reports...

[danielbilling]

Hi David,

Been facing the same battle during the last project, especially when you want to introduce VTB.

They go from my groups work and want to create a VTB board by state. end up with like 14 lanes

[GreatWhiteCodeN]

I too find this confusing.  I will be honest, I have never been impressed with Service Now's state translation (along with many other relations in their DB)  This seems overly-complex when the whole point of ITSM and IT in general is to make it as simple as possible.  The more I use Service Now, the more see inconsistencies and issues.  I have been developing on Service Now for about 5 years now and given the fact that it is a very fluid system, I think the developers just put too many 'bells and whistles' on it and will defend their cause tooth-and-nail.  In reality, any data-driven application whether a true 'program' or a web app could benefit from a MUCH better DB design, including Service Now.  The logic is just too chaotic