Incident placed on hold pending Problem

[GBAKEED2]

Thoughts on the following configuration for incident and problem handling. The tool has been configured so that a major incident can be placed on hold Pending Problem. When you link an Incident to a Problem and set this status, the cause and fix information gets auto copied to the Incident worknotes when the Problem is updated. The Incident also gets auto closed when the Problem is closed. The Problem manager insists this  is standard Servicenow practice. I disagree, incidents are closed following service restoration by either perm fix or workaround. Problems should be investigated independently of the incident

[AndersBGS]

Hi @GBAKEED2 ,

I would always stick with your point of view. Incidents is an service that is interrupted and should be restored as quick as possible - either by er permanent solution or a workaround. Post incident resolution a problem can be created for workarounds to find the permanent solution and by that ensure that there will be no further incidents.

Example: A server goes into hung state and provides an event that gives an incident. The incident can be resolved within mins. if the server is just restarted. Where to find the actually cause of the hung state can take weeks and should be handled in a problem record instead. 

If my answer has helped with your question, please mark my answer as accepted solution and give a thumb up.

Best regards

Anders

[jMarshal]

This is an "antiquated" ("old school", if you will) way of thinking about Incident Management -- where you keep an incident open on hold until it is "absolutely fully resolved" in finality...not just service restored from perspective of the service consumer (which is best practice in 2023 ITSM).

I agree with you and disagree with that thought in principal.

From that perspective, a work-around is not a resolution to an incident -- you put it on "hold" until the work around is removed and "service is restored". Most of the time, those with this kind of opinion ("full resolution only") also feel as though an incident can't be reopened (once closed, it's closed) and many times an incident "isn't really an incident" in circumstances where "the client is doing it wrong", etc...I'm guessing you disagree with those approaches, too. I know I do.

In most modern ITSM practices, an incident is any reduction in service (real or potential) from the perspective of those consuming the services themselves and is restored as soon as the consumer can utilize the service to the level that they expect or consider acceptable. Everything else is at an intersection of a separate ITSM process.

IMO, stick to your guns, but don't be surprised if/when you can't convince those who do not see it this way...

[Sarah Wood]

Interesting discussion! You may also find it helpful to post in the IT Service Management forum. There are some relevant posts there including this one on incident management.