Incident Management clears out the status reason when the status changes to closed. This process is handled at the client and server level. Active Link HPD:IN:Status_100_ClearReason clears the reason on any operation except $QUERY$. Filter HPD:INC:ClearStatusReason_210 clears the reason on change. (There are some issues with the run if statement that I will not discuss here). When the status changes from “Resolved” to “Closed”, we want to preserve the “Status Reason” required in a state of “Resolved” to the closed status.
We have auto-closure enabled and Incidents that have been “Resolved” for 15 days automatically move to a state of “Closed”. When the Incident closes, the “Status Reason” codes, which are required, are removed. This has an impact on our business in the following ways:
- Incidents with “Customer Follow-up Required” or “Monitoring Incident” cannot be screened after 15 days in the “Resolved State”. We may complete Incidents in with these codes with the wish that in 30 days we will contact the customer to make sure the solution is still stable. We cannot do follow up or monitoring past 15 days.
- We have recently ramped up Remedy Knowledge Management. Our agents may come up with temporary workarounds. We would like to record these workarounds in RKM. We cannot identify incidents that have temporary solutions to identify potential Knowledge Entries past 15 days.
- We have just started implementing Problem Management as a process. The problem managers want to identify issues that have temporary fixes or issues that could be removed with enhancements. We cannot use Incident Management as a source of this knowledge past 15 days.
It could be argued that one should a) set auto-closure to a longer set of days or b) set auto-closure off. Using Option A) merely delays the issues we face above. Option B) would require us to build a process for closing Incidents manually.
We believe not clearing Status Reason makes good business sense for three reasons. First, why collect ‘Status Reason’ if the customer can’t do anything with it? Data that is collected should be to support action or be reportable. Status Reason in “pending” supports Service Level Agreements and notification escalations. Since the Incident is “Resolved” and no further action is likely, the only reason the data should be visible is for reporting reasons. But the application clears it out so it is not reportable. Second, the field should be reportable, because the ‘Status Reasons’ themselves imply further action: “Customer Follow-up Required”, “Temporary Corrective Action”, “Future Enhancement”, “Monitoring Incident”. But we can’t monitor if that information if the field is cleared out. Finally, resolution ‘Status Reason’ monitoring is necessary for Problem Management. Problem Managers need to know which incidents need “Future Enhancements” and which incidents should be monitored. Problem Managers should be able to group and highlight incidents that have been closed based on the closing action or reason. This is simply good ITIL process.