Resolving Related Incidents before a Problem is resolved?

[Kristin J]

Hello! I am trying to configure Problem but am running up against issues with notifications and process. 

I thought that Incidents should be resolved when a workaround is available/service is restored, and then the Problem can remain open for root cause analysis. But OOB, Incidents remain open even if the Problem is resolved. This seems against my understanding of the process.

There is an inactive BR to resolve related Incidents when the Problem is resolved, but that can still leave Incidents open after service has been restored. Since the deprecation of the UI action in Problem that resolved related Incidents on-demand, is the process expectation that analysts are resolving all of the related Incidents manually, or leaving them open until the Problem is resolved?

Additionally, if I do turn on the close-related-incident BR, when a Problem is set to Resolved it triggers a comment to all the Incidents and sets them to resolved. However, because there is also a "send notification when incident is resolved" BR, the user gets two notifications.

We are a small team so we don't have Incident Manager/Problem Manager separation like in large organisations, and monitoring when to close incidents that have already received a workaround through a Problem seems onerous. I'm curious how others are managing this part of the process. Thanks for any feedback 🙂

Kristin

[Utpal Dutta]

Hi Kristin,

I understand that you're struggling to understand the Problem Management process so let me explain a bit.

Problem record is created when you receive multiple similar Incidents and since these Incidents are recurring you may want to find out the Root cause of it that is why in Problem record we have RCA. However an Incident can be closed by providing a workaround.

So it makes sense that when you receive multiple Incidents with similar issue then create a Problem record and work on that Problem record to find an RCA. Once RCA is completed you can Fix the problem and Resolve it. Once Problem is resolved you can mark it complete and then you can use Resolve Incidents UI action to resolve all the related Incidents by working on a single Problem.

I would highly recommend that you follow the best practices suggested by ServiceNow in their Problem Management documentation.

Please mark my answer correct if it was helpful.

Thanks,

Utpal

[Kristin J]

Hello, thanks for replying. I don't believe I'm struggling with the concept/process of Problem Management. I previously reviewed the best practices from ServiceNow because they have deprecated/removed that Resolve Incidents UI action from the Problem workflow. This makes closing Incidents a more tedious, manual effort. That being said, I may re-enable/modify the UI Action in order to help my team more efficiently close any related incidents.

[Dr Atul G- LNG]

In my career, I’ve worked as a Problem Manager for a short period, and I agree with your perspective. The fact is that an incident can be resolved if there is a workaround available, while the problem can remain open. Out-of-the-box (OOTB) ServiceNow deactivates the Business Rule (BR) for this because, in many organizations, incidents are resolved as soon as a workaround is identified.

Now, for the second part: if we activate that BR, incidents will only resolve once the problem is closed, which can take significant time (e.g., 15–20 days). Keeping incidents open for such a long period negatively impacts SLAs and KPIs. Additionally, the primary purpose of a problem is to identify the root cause (RCA), not to delay incident resolution.

Practically speaking, your team would need to resolve incidents manually while the problem investigation continues.

[Kristin J]

Thanks for the reply. From a process perspective, do you think there would be any issue (conceptually) with re-activating the UI Action that was part of Problem up until London? It resolves all related Incidents but leave the Problem open. It was disabled, though, as part of the Problem Migration utility which moved us to the guided lifecycle model.