Should Problems Auto Resolve Incidents?

nickm5816667392 · 3 weeks ago

Hi all, l'm receiving conflicting information and would like to know what the majority of others are doing.

We're in the middle of implementing Problems in our ITSM platform. We're running Zurich.

Looking to know how others are handling:

Does resolving a Problem automatically resolve the incidents that are linked to it? If so, where do the resolution notes for the incidents come from? Is it coming from the "Fix notes" section? I took that as detailed information written by IT that explains in detail how the problem was fixed. I don't look at it as high level notes that the end user should receive.
Are you utilizing the Communicate Workaround or Communicate Fix (kind of ties into my question 1 above) at all? In our environment these buttons work, but they simply add a work note to the affected incidents. We only have the system set to email the caller for comments. Work notes are supposed to be internal.

As always, appreciate your insight! This community has been super helpful in getting us through our ServiceNow journey.

Its_Azar · 3 weeks ago

Hi there @nickm5816667392

A resolved Problem means the root cause is fixed, but incidents may still need validation from support teams or users.

Also, I’d avoid exposing the Problem “Fix notes” to end users since those are typically internal details.

For the Communicate Workaround/Fix actions, OOB they mainly create work notes on related incidents. Since work notes are internal, users won’t get emails unless you customize the notification logic or use additional comments instead.

So it should be like thhis-

Fix notes = internal technical details
Additional comments/customer updates = user-facing communication

☑️ If this helped, please mark it as Helpful or Accept Solution so others can find the answer too.

Kind Regards,
Azar
Serivenow Rising Star ⭐
Developer @ KPMG.

View solution in original post

ElizabethA20437 · a week ago

The suggests that your incident is "waiting" for the problem process to find a root cause. This goes against the reason why the industry split problem and incident all those years ago. The goal of an incident is to restore service... not to find the root cause although if the root cause is known or discovered then that is great.

Putting incidents on hold "waiting problem" will drive up your Service Downtime. Typically to start with the advice would be to open problems when incidents are resolved when the root cause needs investigating or remediating.

In more process mature organizations, problem can be run along side incident although that takes some discipline to maintain the goal of incident management to restore service and not let thoughts of finding root cause delay that objective. Then, of course there is the question of repeat incidents that could be attached to an open problem, especially where a workaround is not established or is fuzzy.

Personally, I would not auto close these tickets, and I would be careful about sending the technical problem summary directly through to end users. I would include a triage at the incident level.

nickm5816667392 · a week ago

Thank you for this. We made the decision not to share anything with end users from Problems at this time. We're also not going to allow Problems to close incidents.