Old Incidents are open but have no workable task.

Products

• ServiceDesk

Issue/Introduction

Incidets that have spent a long time in the Work Incident Stage no longer have a workable task but the Incident otherwise appears to be open.

Long time here would be:

• More than 500 days in ServiceDesk 7.5/7.6
• In case of ServiceDesk 8.0 more than WorkIncidentTaskTimeoutInDays setting in ServiceDeskSettings

Environment

ServiceDesk 7.5
ServiceDesk 7.5 SP1
ServiceDesk 7.6
ServiceDesk 8.0

Cause

There are two things at work here:

1. Work Incident task has a timeout that is hardcoded to 365 days in ServiceDesk 7.5 and 7.6. Work Incident task having a timeout is intended behaviour.
   Due to the way this timeout is configured (skipping weekends and holidays), the timeout actually triggers at 514-516 days (at the time of writing in Feb 2017 this would be Incidents created in September 2015). The way the timeframe for timeout is set has been changed in newer versions - in SD 8.0 it is no longer hardcoded but is a modifiable configuration setting (WorkIncidentTaskTimeoutInDays in ServiceDeskSettings).
2. There is a defect in how that timeout is handled. The intended behaviour is tickets timing out and being closed with the close message that they timed out. Due to the defect, this closing does not happen.

Resolution

The approach to address the issue depends on the ServiceDesk version:

ServiceDesk 8.0

1. Timeout can be changed to value beyond what you expect is needed by changing WorkIncidentTaskTimeoutInDays in ServiceDeskSettings
2. The defect with Incidents not being set to Closed properly is fixed in ServiceDesk 8.0 HF6.
To address affected incidents created before installing SD 8.0 HF6, the approach is the same as section 2. below.

ServiceDesk 7.5/7.6

1. In ServiceDesk 7.5/7.6 there is not much we can do to prevent timeout from happening due to timeout being hardcoded. A workaround would be to manually send Incidents out of the Work Incident task and then back into it which will reset the timeout time. The only good way of doing that is setting Incident to be On Hold and them remove it from Hold. On Hold should not be resetting SLA, it will pause them for the duration of being On Hold (this is hardcoded in the project). If going through Hold for just a moment and then back to Work Incident, the impact to SLA should be minimal.

We would recommend setting up a report of open incidents over 500 days old. That could then be acted upon, either going through setting incident On Hold and back or making sure Incident is Resolved before timeout occurs.

2. Affected tickets are effectively closed, the tasks are properly finished, there are no messages or any other remains left. Since tasks are properly finished and process has reached the end of workflow, there is no way to get them back into workable state and the solution would be to set the information to indicate these are closed.

The goal here is to make sure reporting works correctly and these tickets do not show up where these are not expected by adding or modifying the information for tickets that may need to be reported on or that will show up in reports

Note that modifying database directly is always dangerous and as such the last resort. Please read through rest of the KB article and make sure you understand what is required to be done. Before running the UPDATE queries below, make sure you have a full backup of the database.

Here is a query that can be used to find affected incidents:

SELECT
im.ProcessId,
im.TicketStatus,
rp.Result,
rp.PercentComplete
FROM ImIncidentTicket im
LEFT JOIN Task t ON im.WorkResolveTaskId = t.TaskID
LEFT JOIN ReportProcess rp ON im.SessionId=rp.SessionID
WHERE im.CurrentTask='WorkResolve'
AND im.WorkResolveTaskId LIKE '%'
AND t.IsCompleted = 1

Here are two queries to get the same list of incidents marked as Closed. They need to be run in this order, ReportProcess table to be updated first and ImIncidentTicket table second because WHERE in the inline SELECT for the list of incidents is based on ImIncidentTicket.CurrentTask. Both should affect the same amount of rows that the SELECT above returns.

What this query to update ReportProcess table does is simple - sets the status to Closed, completion percentage to 100% and sets the end date to current time (better to have a time in it rather than leaving it empty).

UPDATE ReportProcess
SET Result = 'Closed', PercentComplete = 100, ProcessEnded = GETDATE()
WHERE ReportProcessID IN (
SELECT
im.ProcessId
FROM ImIncidentTicket im
LEFT JOIN Task t ON im.WorkResolveTaskId = t.TaskID
LEFT JOIN ReportProcess rp ON im.SessionId=rp.SessionID
WHERE im.CurrentTask='WorkResolve'
AND t.IsCompleted = 1
)

Now, we also need to update ImIncidentTicket table. Please replace [email protected] in the query with a valid user's primary e-mail address - an administrator user would probably be a good choice to not confuse reporting and statistics.

UPDATE ImIncidentTicket SET
TicketStatus = 'Closed',
CurrentTask = 'None',
ResolvedBy = '[email protected]',
ResolutionDate = GETDATE(),
CloseCode = 'Timed Out'
WHERE ProcessId IN (
SELECT
im.ProcessId
FROM ImIncidentTicket im
LEFT JOIN Task t ON im.WorkResolveTaskId = t.TaskID
LEFT JOIN ReportProcess rp ON im.SessionId=rp.SessionID
WHERE im.CurrentTask='WorkResolve'
AND t.IsCompleted = 1
)