Incident should automatically closed after creating problem ticket from that incident.

[Aamir Khan]

Hi Team

We create Problem Ticket based on re-occurrence of similar incidents. After problem ticket created, that incident should automatically closed. This is what the customer want.

How can we achieve this?

#caservicedesk17.0 
#ca_sdm_17.1
#problemticket
​​​​

[Kyle R]

Hello Aamir,

It sounds like you need to attach an Event to your Incidents that detects (Conditional Macro) when the "Problem" field is populated. Then it performs a Close/Resolve.

I'm not sure why you would want to do this though. Typically an Incident stays open until it is Resolved, not "Until a Problem is created." As otherwise the end user loses contact with the final resolution of the Incident.

Typically, you would want your Analysts to be making a decision "Yes, this Incident is resolved by this known Problem. Close." And not "I'll log a new Problem and it might resolve this Incident at some point. Close."  Because that could lead to a blow-out in the number of unresolved Problems. Typically, you want to try and keep the Problem count down to things you really want to work on. 


Let me run through a little about the difference between "Linking" and "Parent/Child" Relationships in ITSM, as it may be relevant.

https://docops.ca.com/ca-service-management/17-2/en/using/ticket-management/create-a-parent-child-relationship


1) There can be a link between some different ticket types.
This is a one to many relationship.
For example:
* An Incident can be only ever be linked to a single Problem.
* A Problem can have multiple different Incidents linked to it.
* There is not a "Close All" for the linked tickets on the Problem.

2) There can be a Parent to Child Relationship in the same ticket type.
For example:
* One Problem can be the Parent of many Child Problems.
* ITSM includes a "Close All Children" option (providing they meet conditions for closure otherwise).

Your scenario is:

>> We create Problem Ticket based on re-occurrence of similar incidents.

That's fine.

A) Are you going to follow (1) and create multiple Incidents that link to a single Problem?
This is for the scenario where there is a single Problem, and people are logging lots of Incidents about it. For example, your authentication server is down (one known Problem) and there are multiple Incidents raised of "I can't log in."

OR 

B) For each Incident that is logged, it will get its own Problem.  Then that Problem will be linked as a Child to a Parent Problem.
This is the scenario where you receive lots of "I can't log in" Incidents, but there are multiple Problems such as "The authentication server is down" OR "One user group got pushed the wrong login forms" OR "Undiagnosed login Problem - we're not sure yet."


If you think that you're closer to "B" than "A" then you definitely do not want to be closing Incidents at Problem creation. 


Thanks, Kyle_R.

[Pier Olivier Tremblay]

Kyle, I must say that I love to see intelligent answer like this one. You would make a wonderful consultant :)

On top of that, I want to add:

It is okay to close an Incident even if the underlying problem is not resolved.
Incident management is not about resolving root cause, it is about restoring service to your client to respect SLAs.
If you can provide a walkaround to your customer, then the incident is resolved.


On the other hand,if you simply want to convert an incident into a problem, keep the following in mind :

Closing an incident when a problem is opened is often a way to respect SLAs since problem are rarely subject to the SLAs defined with your customer. Converting incident into problem to keep good statistics about SLAs breaches is a bad practice.



And finally, incident and problem are not necessarily related, a problem may exist if IT team is aware of something weird and it may not had any impact on customer at this point.





​

[Kyle R]

Thanks Pier,

I'm learning too!

Pending Aamir to see if they need more assistance and on which scenarios.

Thanks, Kyle_R.

[Aamir Khan]

Thanks Kyle for detailed explanation . I'll communicate the same to the customer.

Many thanks.