1 2 Previous Next 16 Replies Latest reply on Feb 4, 2016 3:31 PM by dennistaylor

    Master Incident vs. Problem

    SusanJS Specialist

      Is anyone using the Master Incident function?  We're currently using Problem Management to link Incidents together.  Just wondering what might be the thinking behind using one over the other.

        • 1. Re: Master Incident vs. Problem
          wynnb Specialist

          I'm not using Master Incident, but just posted a related question. If you're linking incidents to Problems, how are you handling the resolution of the incidents from the Problem?

          • 2. Re: Master Incident vs. Problem
            tbirnbaum Rookie

            We have being using this concept for years now in ITSM and now in HEAT.  When we upgraded from ITSM 6.3x to HEAT 2014.2 we had our HEAT consultant bring the concept over, we call ours Lead(master) and Linked incidents .  When receiving multiple calls on the same issue within the same time period we create a Lead incident and Link all associated incidents to the Lead.  All communication is processed on the lead which then is transferred to each linked incident, as well when the Lead is resolved that is pushed down to all Linked incidents - making all that a lot easier to manage.  Works great!  Next - we need to tackle Problem Management - as we have incidents that have been fixed but are being left open indefinitely for additional analysis to determine a definitive cause and/or to watch to see if issue reoccurs.

            • 3. Re: Master Incident vs. Problem
              SusanJS Specialist

              We basically use the out of the box process which is that when the Problem ticket is set to Closed, set all linked Incidents to Resolved.  There's a business rule that triggers when the Problem is set to Closed status and it runs the Quick Action "Resolve Incident from Problem".  We have it set to write the Problem resolution as the Incident resolution.  You could probably tweak it so that it triggers on Problem resolve instead of close.

              • 4. Re: Master Incident vs. Problem
                wynnb Specialist

                What happens if there are open tasks on the incidents? Our system won't allow incident resolution if the tasks are not completed - do you have that rule enabled?

                • 5. Re: Master Incident vs. Problem
                  SusanJS Specialist

                  We do, but we currently don't use Tasks a whole lot.  We do run into similar issue when the Incident is incomplete (i.e. required fields are missing, which happens if customer reported it through our automated Voice system) and the Problem cannot be closed, so I basically go through and find the Incidents causing the error, fix them, then run the rule again.  The only simple thing I can think of is to create a report or saved search that would tell you which Incidents still had incomplete Tasks so you can tackle those before trying to close the Problem.

                  • 6. Re: Master Incident vs. Problem
                    wynnb Specialist

                    Thanks Susan - that helps.

                    • 7. Re: Master Incident vs. Problem
                      SusanJS Specialist

                      The way you handle your Lead Incidents sounds like the way we handle it through the Problem Management module.  We link all related incidents to a single Problem, then when the Problem gets closed, the linked Incidents also close.

                      • 8. Re: Master Incident vs. Problem
                        tbirnbaum Rookie

                        We will be upgrading to HEAT 2015.2 in a few weeks, and we are hopeful that code will prevent you from linking an incident to multiple leads and/or the lead linked to itself.  We have experienced this several times, and had to create a db query which we run as a daily report to find/correct.

                         

                        In our Resolved Lead process, it will manually update all linked incidents fields that are required for closure.  We also complete any open tasks at that time as well.  It would make sense to have logic in all incidents that upon resolving or closing an incident it "checks" Task for any non-completed assignments and prevents you from doing resolve or close processing!  We also have the report that runs daily to find any close incidents that have non-completed tasks so we can correct.  

                        • 9. Re: Master Incident vs. Problem
                          Apprentice

                          I don't have this setup so apologies if I have the two objects and quick actions (QA) placement wrong but I'm guessing the QA that is set up to close incidents is in the Incident list.

                          Can you not create a new QA in the task list which closes all open tasks then append to the incident closure QA a a new run for child with the relationship set to something like IncidentAssocTaskAssignment and using the new task closure QA you set up?

                          • 10. Re: Master Incident vs. Problem
                            chris1 Apprentice

                            We are going to be using both Problem Management and a customized version of the Master Incident functions found in the app store.

                            Problem Management meets our need for items where we wish to apply more formal problem management. We are looking to the Master Incident functions to perform very similar related incident processing without the additional overhead that Problem management introduces.

                             

                            For instance, we don't need to follow formal problem management for a cable cut that disrupts the network, but we do want the ability to crate a master incident that will resolve related incidents when the issue is resolved.

                            • 11. Re: Master Incident vs. Problem
                              wynnb Specialist

                              Thanks Chris,

                               

                              Yes, that is the path I want to take, but there is another rule that says: when you complete the last open task on an incident, prompt the user for whether they want to resolve the ticket, or create another task. If they say 'yes', it prompts for the cause and resolution. I'd need to be able to bypass that rule for this particular case (I like having that rule in place otherwise, because it prevents Techs from leaving tickets open after they've completed all the tasks).

                               

                              What we need is some logic to: set all child tasks to 'completed' status (bypassing other rules), then copy the workaround or resolution from Problem into each linked Incident and set the 'Cause' field, then set the incident status to 'Resolved'.

                               

                              I opened a support ticket on this, but they keep telling me they don't really help with 'design' issues. To me, this is a design flaw out of the box, not a customization. You shouldn't be able to resolve incidents if there are open tasks, but you should be able to resolve them via Problem. Out of the box, you can only have one or the other. I haven't tried the Master Incident process, but I would think it would have the same issue.

                              • 12. Re: Master Incident vs. Problem
                                Apprentice

                                Could you not set the expression on the required business rule to also check if you have any linked problems and only apply if there isnt?

                                 

                                Incidentally, how have you setup the rule to not allow closure until all tasks are closed?

                                • 13. Re: Master Incident vs. Problem
                                  SusanJS Specialist

                                  It was already there, out of the box, but disabled.  We just had to enable it.  It's a Validation rule in Incident:

                                   

                                  $(Status != "Closed" && Status != "Resolved" || IsTrueForAllChildren("Incident#", RecId, "Task#Assignment.Rev3", "$(Status == 'Completed' || Status == 'Cancelled'|| Status == 'Rejected')"))

                                  2 of 2 people found this helpful
                                  • 14. Re: Master Incident vs. Problem
                                    ben.prinsloo1 Apprentice

                                    This is more around process and terminology. Problem management kicks in when a bunch of recurring incidents, closed or active, are being investigated why they keep on popping up. There is an investigation which could lead to a Change on some point to fix the underlying issue of the recurring issue. This is not handled by the service desk analysts since they deal with the incoming incidents, and only attempt to resolve them as soon as possible.

                                     

                                    The master incident is to cluster a bunch of related active incidents together which haven't been resolved yet, ie. done by the service desk analyst. For example, if the email is down, a lot of calls comes in on the subject. Instead of assigning all of them individually, or deal with them individually by the helpdesk, they are bunched up with the active master incident. When the master incident is resolved, the resolution is propagated to the sub incidents and resolve the whole lot. This can of course form the basis for a Problem is this is a recurring issue to investigate why the email server keeps on dying.

                                     

                                    Does this make sense?

                                    2 of 2 people found this helpful
                                    1 2 Previous Next