- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-13-2015 01:17 AM
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?
Solved! Go to Solution.
- Labels:
-
Incident Management
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-06-2015 08:40 AM
Finally this is now fixed.
It was, as many of you suggested a Business Rule on the Change Request table that we got a part of the StartNow configuration. It is called SNC - ITIL - Update related Incidents. It was querying on the wrong field label in the incident table - change_id instead of rfc. No results were obtained as the query was invalid and this resulted in all incidents being set back to Active Work in Progress every time any change was closed completed. This was regardless of whether the incident was related to the change or not.
Changing to the correct field label fixed - one minutes work after a heck of a lot of troubleshooting!
Many thanks all of you for your help with this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-21-2015 12:31 AM
Hello,
We have recently faced the similar problem and we figure out that there were some OOB Business rules written on the task table creating this mess.Most of the time we end up in searching only Incident Table, i suggest to check at Task level as well.
Hope this helps
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-23-2015 06:30 AM
I have checked incident and task BRs.
It is still happening
I may be reading the logs wrongly but I think this says that I was working on change requests at the time:
This is also happening with other users where it says they have changed this state but they say they have not even opened the incident.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-23-2015 06:49 AM
Ok, let's take this one step at a time:
If I read you images correctly, the state on the incident changed unexpectedly at 10:18.
According to the transaction log, you we operating on a form at that time.
So it looks like your action did result in the change to the incident, though it was not your intention.
Here's some questions for you:
1. What type of record were you updating at 10:18? ( I'm guessing it was a change request )
2. Are there any change requests related to the incident in question?
3. What is the numeric value associated with the incident state of "Work in Progress"?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-23-2015 06:58 AM
1. I was updating a change request at the time
2. No, there are no change requests related to the incident.
3. Work in Progress is 2 and Awaiting change is 8 - this is the same for both state and inc_state. We are using state in the form.
Does this help?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-23-2015 07:21 AM
It helps in that it rules out a scenario that I had in mind .
That said, it still looks like this incident was changed in a thread of execution involving business rules fired off in the update of the change request.
Can you turn on "Debug Business Rules" and make a similar edit to the change request as before?
Since the incident is not directly related to the change, I suspect that the change has a related record which in turn is related to
the incident ( and there could be even more indirection involved ).
For example, closing the change might fire off "SNC - ITIL - Close Related" which could close a related problem record.
That problem record could then fire off the BR "SNC - ITIL - Update Related Incidents" which could update your incident.
It may not be this exact sequence, but look for something like it.