Incident State changing automatically

[csellens]

We have a strange   situation where the state on some incidents changes from Active - Awaiting Change back to Active - Work in Progress. The journal says that I changed them, but I didn't - or didn't think I had. According to the log I was working on updating completely unrelated change requests at the time on at least 2 of the times this has happened. This does not seem to be consistent in that some incidents stay in this state and others change.

I am fairly sure that we did not do any customization around this state and have checked through the business rules, client scripts and UI policies and cannot find anything there. We are using Fuji

Any ideas on what could be causing this?

[csellens]

OK thanks, I will take a deeper look.

I have worked out that this seems to happen when change requests are being worked on by the person who is supposed to have edited the incident. I have this evidence from 3 incidents so far. So I am going to switch my attention to the change business rules.

I could imagine a scenario where in order to do something like render the All active changes list, a check may be made on all incidents awaiting change and if no change request was related to them, then the system kicks them back into the active - work in progress state.

[HugoFirst]

Building on the idea that the problem is caused by a series of business rules executing in response to an updated change request:   If you have 3 specific incidents where this has occurred, I'd also look for commonality among those records.

Some questions to keep in mind:

Do the change requests being edited have any related records?

Do the affected incidents have any related records?  

If the answer to both questions is yes,   then look for records in common to both.

If you can build a web of related records that connect the incident record to the change request, you've got a good start.

[csellens]

Hey!

Think I have found the culprit - looking at the log entries for the session where some of these were changed, I found that a business rule called Run SLAs was running on all the incidents at the time their state was changed. See below.

It even helped me to find some incidents that we had not realized had been changed but they have.

Now I just have to find out why this rule is changing the state - a job for ServiceNow I think as the script just says:

// run the 2011 SLA Engine, if 'com.snc.sla.engine.version' is set to '2011' (default for new installs)

// run asynchronously, if 'com.snc.sla.process.async' is set to true. (default false, for new installs)

new TaskSLAController(current).run();

This seems to use Process SLAs which has a suspicious line in it "taskSLA.stage = 'in_progress'. Maybe the code has a handle on the wrong object at this time.....

Will report it to HI and see where this goes.

[HugoFirst]

I've had very good luck with ServiceNow support and expect that you'll soon have a solution.

May I ask one thing of you?   When you get the solution, would you post it here?   This is not one of your "run of the mill" issues and I would find it educational to learn about the problem and its solution.    

Thanks in advance!

[bammar]

I had a Similar issue with a State Called Awaiting Problem appearing for Stories.   To cut through a lot of frustration let me advise the following: Are these incidents children or parents of another task like a change ...... If so check the time stamp of when their states changed to   Awaiting Change - then go to check the Child or Parent Task and see if a change in state appeared a few seconds before.   Then work back and see what is triggering the other change.