Incident States

[Michael Miller]

We are taking a look at our incident states and we were looking at the new incident state model in Helsinki and  doing some analysis on if we should move to that or not.  When we started off we added several extra incident states to incident, and I think the values (on the Choice Table) may have been set incorrectly.  I have read that we should keep states that are "active" at a value below 6 because 6 is resolved, 7 is closed.  

I am wondering how others are setup in their current systems?  here is how we are setup today (number is the state value on the Choices table):

1 - New

2 - Assigned (Ticket has someone assigned to it and it is being worked)

12 - Referred (Ticket has been assigned to a group, but not to an individual yet)

4 - Awaiting User Info

5 - Awaiting Evidence

10 - Awaiting Change

8 - Awaiting Vendor  

11 - Awaiting Vendor Change

6 - Resolved

7 - Closed

[robpickering]

Michael,

For what it's worth, unless you started with a clean Helsinki instance (did not upgrade to Helsinki), you cannot leverage the new Incident Management State model, see here for details:   Incident management state model   (also covered in this KB: ServiceNow KB: Incident Management State Model (new in Helsinki) (KB0564465) )

That said, you do want to keep Closed states together, so you can leverage logic like "if (current.state < 7)" in order to perform actions on non-closed Incidents (this type of logic is already in the system in places, so if you've created non-closed states that are higher in value, they may get treated as closed).   The Incident Management State model was built to help clean some of this up, but it cannot be retrofitted.

At my last company (no Incident State Model), ours looked like this:

The only change we made to the OOB states was to add an "Awaiting Vendor" state (which paused some SLAs).

-Rob

[Michael Miller]

So if you have more than 5 states like we do, what would be the best way to look at doing this and changing the values so they are better aligned with best business practices.

Also right under the first line where it says it is not available, it then says:

My thoughts are Im going to have to go through and do that work anyways if I change the values (numbers) on my states to align with best business practices, so wouldn't it be beneficial to follow the new model instead?

Thanks

[robpickering]

There is information on the Docs site about how to map from the old to the new...if that's what you want to do.   Of course, you'll also have to a lot of testing to ensure you haven't built business logic around the old states that would now break.

We added negative value states (not best practice now) for the one that we added.

-Rob

[Teena Singh]

Michael,

Glad to see that you are using the Community to learn more.

The Customer Experience team is striving to ensure that customer queries posted from the HI Service Portal are answered in timely and accurate fashion.

If you feel your question has been resolved, please mark the appropriate reply in the thread as being the Correct Answer.

This enables other customers to learn from your thread.

Thank you in advance.

If you are viewing this from the community inbox you will not see the correct answer button.   If so, please review How to Mark Answers Correct From Inbox View.

Regards,

Teena Singh
Customer Experience: UX Strategy and Customer Insights
teena.singh@servicenow.com

ServiceNow