Can we reopen a Closed incident ?

[shaik_irfan]

Can we reopen a Closed incident ?

If yes can anyone help me on this

[Dennis R]

Just to expand the above:

The system will autoclose incidents after a set amount of time. The window is configured via a system property called glide.ui.autoclose.time, and can be set here (substitute your instance name for the word instance😞

https://instance.service-now.com/sys_properties.do?sysparm_query=name%3Dglide.ui.autoclose.time

There is an scheduled job called Autoclose Incidents that checks every hour to for any incidents that should be autoclosed. It works by firing off a business rule called incident autoclose:

https://instance.service-now.com/sys_script.do?sysparm_query=name%3Dincident%20autoclose

If you want to affect how the autoclose mechanism works (for example, by setting it to close after a certain number of business days instead of calendar days), that's the best place to make your modification.

Having said all that...

Once an incident is closed, I beg you, PLEASE do not allow people to reopen it. That's almost always extremely bad practice, and the cause of much angst and woe. If you do so, this is almost certainly because your processes are messed up, not because the system is doing something wrong. That's why ServiceNow functions the way it does out-of-the-box.

Generally speaking, the Resolved status means, "We have taken remediation steps and we think this is working." It usually accompanies notifying the user or caller that you believe that business service has been restored. On the other hand, Closed status means, "We have verified that business service has been restored," and is usually the result of the customer or caller himself or herself acknowledging that whatever it was that was broken is now working correctly. The reason for the autoclose mechanism is that realistically, customers often do not inform the Service Desk or fulfillment group that everything is fine, so it's just a way to say, "If we don't hear from you after x amount of time, we're going to assume that all is okay."

If a customer or caller has further issues, this should be considered a recurrence of the incident, and a new incident opened. This allows for better tracking of incident occurrence, which can then be used to trigger things like problem ticket creation.

The other common reason that incidents might be reopened is because you want to do some kind of post-incident reporting. That's what my company is facing right now. Three or five days after an incident is closed, they want to go back in and update the actual time an incident started, for example.

For those such cases, I highly recommend instead to create reporting-specific fields on the incident table (for example, "Actual start time") that are unlocked by ACL even after an incident is closed that can be updated indefinitely. Set up some business rules to copy the incident open time by default so that you'll have data even if no one bothers to fill in the field, and do your reporting off of that field instead of, for example, the incident open time.

If there's a specific one-off need to edit something on the incident that was just plain hideously wrong or as a result of some other process running amok and corrupting your data, do it via a background script instead of making something as dramatic as a policy change to allow incidents to be reopened.

As a side note, if you decide to go forward, you're not really saving yourself much trouble. If you do allow incidents to be reopened, you'll also be bypassing things like workflows that might be associated with the incident, SLA calculations, etc. All in all, I hope to convey to you that allowing closed (that is, not resolved) incidents to be reopened has probably the highest bad-idea-to-frequency-of-being-asked ratio of any idea I run across in Service Management.

If you need something to back you up officially on this because management is pushing down on you, see if you can snag a copy of the ITIL Service Operation book and look at the section on incident management.

Hope this helps,

--Dennis R

[shaik_irfan]

Thanks Dave.... That helps

[mandarm]

Lets quote the actual ITIL portion to closure so there is actual context here. There are valid reasons to reopen tickets and not what you mention - yes there should be parameters around those that will vary from org to org.

---

4.2.5.9 Incident closure The service desk should check that the incident is fully resolved and that the users are satisfied and willing to agree the incident can be closed. The service desk should also check the following: Closure categorization■■ Check and confirm that the initial incident categorization was correct or, where the categorization subsequently turned out to be incorrect, update the record so that a correct closure categorization is recorded for the incident – seeking advice or guidance from the resolving group(s) as necessary. User satisfaction survey■■ Carry out a user satisfaction call-back or email survey for the agreed percentage of incidents. Incident documentation■■ Chase any outstanding details and ensure that the incident record is fully documented so that a full historic record at a sufficient level of detail is complete. Ongoing or recurring problem?■■ Determine (in conjunction with resolver groups) whether the

incident was resolved without the root cause being identified. In this situation, it is likely that the incident could recur and require further preventive action to avoid this. In all such cases, determine if a problem record related to the incident has already been raised. If not, raise a new problem record in conjunction with the problem management process so that preventive action is initiated. Formal closure■■ Formally close the incident record. Note that some organizations may choose to utilize an automatic closure period on specific, or even all, incidents (e.g. incident will be automatically closed after two working days if no further contact is made by the user). Where this approach is to be considered, it must first be fully discussed and agreed with the users – and widely publicized so that all users and IT staff are aware of this. It may be inappropriate to use this method for certain types of incidents, such as major incidents or those involving VIPs etc. 4.2.5.10 Rules for reopening incidents Despite all adequate care, there will be occasions when incidents recur even though they have been formally closed. The choice made must consider its effect on data collection, so the reoccurrence and associated work is clearly recorded and accurately reported. Because of such cases, it is wise to have predefined rules about if and when an incident can be reopened. It might make sense, for example, to agree that if the incident recurs within one working day then it can be reopened – but that beyond this point a new incident must be raised, but linked to the previous incident(s). The exact time threshold/rules may vary between individual organizations, but clear rules should be agreed and documented and guidance given to all service desk staff so that uniformity is applied.

----

I am vehemently against auto closure in particular without specific safeguards  - an especially egregious one being that an incident should not be closed with no customer interaction and a verifiable log audit of that interaction. One way to achieve this is via "customer nag" emails/texts that ask the customer whether they would like to close and as long as the customer clicks on no (generating a log record) then the incident should NOT be closed. Plain and simple. Most of the service now pain comes from this "out of the box" auto close behaviour - it should be OPT IN not OPT OUT. 

[Ramon Espinosa]

We have a similar request, however it's not to reopen a closed Incident but to give access to certain individuals to edit certain fields on a closed Incident. Does anyone know how to do this?

Fields to edit would be:

• Category
• Sub Category
• Impact
• Urgency
• Configuration Item
• Resolution Code
• Caused by Change
• Change
• Problem