Updating multiple incidents linked to a single problem

[sn_n00b]

Hello all,

I'm looking for the best way to update multiple incidents that are linked to a single problem.

If there are 60 open incidents, and we have need to update them, do we edit each one individually?

Thanks for any suggestions/help.

[Michael Fry1]

Out of the box there is a UI action: Communicate Workaround that will copy all Problem history to the attached incidents. That's a 1 time copy versus constant updates.

[Steven Young]

a Business Rule is going to be your best Bet.   on your incident form, is do you have the Problem field there?   Field name   "problem_id"   ?   and that is how you are linking them?

If so,   Create a Business Rule.

Name: Update Problem Children       *Yes, pun intended*

Table:   Problem

Active:   True

Advanced:   True

When:   Can be Before or Async   (depends on your needs)   Before will update all the records immediately.   Async will save the problem and then update all records soon after.   (if you just "save" and stay on the form, your updates will not be reflected immediately).

Order:   Whatever you need,   mine is 100

Insert: True
Update: True

Filter Condition: none

Set Field Values: None

Condition:   none

Script:   (will run everytime a problem is update or an incident is attached to the problem.

//function onBefore(current, previous) {

   //This function will be automatically called when this rule is processed.

   updateProblemChildren();



   function updateProblemChildren(){

   var num = current.number;

   var incident = new GlideRecord("incident");

   incident.addQuery("problem_id", "=", current.sys_id);

   incident.addQuery("incident_state", "!=", 6);

   incident.addQuery("incident_state", "!=", 7);

   incident.query();

   while (incident.next()) {

   incident.impact = current.impact;   //Will set incident impact the same as the Problem Impact

   incident.urgency = current.u_complexity;   //Will set incident Urgency the same as the Problem Complexity

   incident.assignment_group = current.assignment_group;   //Will set the Incident Assignment Group, to the same as the Problem Assignment Group.

   incident.update();

   }

   // gs.addInfoMessage('Related Incidents have been updated with the Problem Information');

   action.setRedirectURL(current);

   }

   //}

What this will do is when a problem is updated/saved, it will query the incident table for all incidents where the current sys_id of the problem is listed in the incident "Problem" field.   Then it will find all of the ones where the incidents are not Resolved or Closed and update the Impact and urgency (which in turn updated the read only field of "Priority"   and the assignment group.

This works GREAT to keep all tickets that are assigned to the problem uniform with certain fields.   you can add more fields if you wish.

you can create a business rule that just updates the "work_notes" field from the problem to the incidents.   or however you want.   You can edit lines 13-15 as needed.   or add any other fields before line 16.

Hope this helps.

And i just realized there is an extra line of code in there.   Line 6 we used before but not now.

[Katie A]

Thank you so much this is helpful. Any reason why you commented out the onBefore at the top? Just out of curiosity. Thank you

[Steven Young]

If i remember correctly from way back then,   i believe i commented that out so people wouldn't just copy and paste that part and select async.

from my previous post:

When:   Can be Before or Async   (depends on your needs)   Before will update all the records immediately.   Async will save the problem and then update all records soon after.   (if you just "save" and stay on the form, your updates will not be reflected immediately).

So this way, they have to actually decide which one and set it.

I've done some code on here before and someone copied it and kept getting an error when trying to save.   If i remember correctly that time, the code was for onChange and they were doing an onLoad script.

and just to clarify i did separate the incident states by 6 and 7

1.   incident.addQuery("incident_state", "!=", 6);  
2.   incident.addQuery("incident_state", "!=", 7);  

This is because it's extremly easy to comment out 1 line.   some people want resolved tickets updates,   some dont.   and MOST dont want any closed tickets updated.   So this just gives more freedom and ease of editing to customize as you see fit.

[Steven Young]

also,   just to be blunt..  

you really dont want this onBefore if you have a lot of incidents tied to a problem.   You really want it Async.

after this, i actually changed mine to be Async because it was just so taxing on the system trying to update tons of records before the form actually saved.

We did see some performance issues on some of our larger problems.

if your problems are small,   say maybe 5-10 incidents, onBefore wouldn't be an issue.