THURSDAY, JANUARY 19, 2017

Track Affected CIs in One Place

I

t should come as no surprise to you that, if used properly, your CMDB can be an extremely valuable input to your incident/problem/change processes. This is true not only of the actual CIs, but also the ‘Affected CI’ records that you create. ServiceNow gives you a couple of different places to track this information. The first is the ‘Configuration Item’ field available to all Task types in the system. You can add this field by personalizing the form for any task. The second is the ‘Affected CIs’ (task_ci) many-to-many table. This can be added to any task form in your system by personalizing the related lists for that form.

This setup allows you to track a primary CI or Business Service against a given task in the field on the form, and it also allows you to track multiple Affected CIs against a task if necessary in the related list. What I don’t like about this setup is that these are managed independently so there’s not a single place to see ALL of the Affected CIs in your environment. My solution to this problem has always been to centralize all of this information into the ‘Affected CIs’ related list by copying the ‘Configuration Item’ field value into it. This simple idea gives you a much better look into your Affected CIs for reporting, and allows for more proactive troubleshooting through CI Business Service Maps as an input into your task processes.

This customization is pretty simple and can be accomplished through the application of two business rules. The first business rule sits on the ‘Task’ table and should be configured as follows…

‘Sync CI with Affected CIs’ Business Rule
Name: Sync CI with Affected CIs
Table: Task
When: After
Insert: True
Update: True
Condition: current.cmdb_ci.changes()
Script:

if(previous.cmdb_ci){
   removeCI();
}
if(current.cmdb_ci){
   addCI();
}

function removeCI(){
   //Get Affected CI records for this task and delete the CI if necessary
   var rec = new GlideRecord('task_ci');
   rec.addQuery('task', current.sys_id);
   rec.addQuery('ci_item', previous.cmdb_ci);
   rec.query();
   while(rec.next()){
      //Delete the Affected CI record
      rec.deleteRecord();
   }
}

function addCI(){
   //Get Affected CI records for this task and add the CI if necessary
   var rec = new GlideRecord('task_ci');
   rec.addQuery('task', current.sys_id);
   rec.addQuery('ci_item', current.cmdb_ci);
   rec.query();
   if(!rec.next()){
      //Create a new Affected CI record
      var ci = new GlideRecord('task_ci');
      ci.initialize();
      ci.task = current.sys_id;
      ci.ci_item = current.cmdb_ci;
      ci.insert();
   }
}

The second business rule sits on the ‘CIs Affected’ (task_ci) table and should be configured as follows…

‘Prevent removal/update of primary CI’ Business Rule
Name: Prevent removal/update of primary CI
Table: CIs Affected (task_ci)
When: Before
Update: True
Delete: True
Script:

//Check the parent task to make sure that the CI is not listed there
if(current.ci_item && current.operation() == 'delete' && current.ci_item == current.task.cmdb_ci){
   //Disallow removal
   gs.addInfoMessage('You cannot remove this CI since it is the primary CI on the associated task.</br>Please change or remove the CI from the task form.');
   current.setAbortAction(true);
}
if(current.ci_item.changes() && current.operation() == 'update' && previous.ci_item == current.task.cmdb_ci){
   //Disallow modification
   gs.addInfoMessage('You cannot change this CI since it is the primary CI on the associated task.</br>Please change or remove the CI from the task form.');
   current.setAbortAction(true);
}

Harnessing the power of the CIs Affected (task_ci) table

Once this is done, any change to the ‘Configuration Item’ field on a task record will automatically result in the creation of an ‘Affected CIs’ entry for that same CI. Now you can set up all of your reports for this area against this table. One of the most powerful things you can do with this data is to set up a BSM Map Action icon that can be displayed to show people from within a BSM map which CIs are being affected by different tasks in the system. There’s a great example on the ServiceNow Wiki that shows you how you can do this.

Affected CIs BSM Map Actions

7 Comments

Richard Huss 30-05-2011, 23:56

In the addCI() function I think the line

rec.addQuery(‘ci_item’, ci);

should be

rec.addQuery(‘ci_item’, current.cmdb_ci);

?

Reply
Mark Stanger 31-05-2011, 00:05

You’re right! I was passing that in as a parameter at one point but I removed it. Good catch.

Reply
Rick 09-06-2011, 03:03

Mark

Thanks for the article, very helpful.

Reply
Eric LeMonnier 07-10-2011, 14:58

This is a great article. Now I’m looking to accomplish the opposite as well; to take an Affected CI and populate the Configuration Item (cmdb_ci) automatically. This way we would have some better visibility from a list view and can make it easier to validate a mandatory CI.

Reply
Mark Stanger 08-10-2011, 06:59

I’m not sure what you mean. You can do that with the regular Configuration Item field but it has the obvious limitation of only being able to store a single value. You can set up a business rule to copy an affected CI into the Configuration Item field easily enough, but how do you dynamically determine which CI to put in that field?
As far as the list view goes, you might consider creating a report or module available that points to the ‘task_ci’ table so that people can easily see which tasks are impacting a given CI. You could even set up a related list on CI forms showing all of the associated tasks. You would just want to ensure that people couldn’t modify that relationship from any place other than the Affected CI list on a task.

Reply
Joe 26-06-2012, 06:25

Mark,

This is a great article, and I am looking to implement this for our Service-Now instance, however I have one question. Do you know if there is a way to copy the Short Description of the task to the task_CI table? When looking at the related lists, I think having that bit of information available to end users would be beneficial, so that they can tell what task is what instead of opening the tasks.

Reply
Mark Stanger 26-06-2012, 06:55

Good question. Because ‘task_ci’ references the task table, and ‘short_description’ is a task field, you’ve already got access to the data you need. You should be able to get to the short description by drilling into the task field.

Reply

Leave a Reply


Latest Comments

  • David: It appears that I can hit sys_properties table with REST. This works, but I haven’t yet discovered the...
  • Mark Stanger: Hey David, It doesn’t surprise me that scoped apps have made this more difficult. I’m not...
  • David: Mark, do you have an example of how to do this in a scoped app? It seems there are many hoops to jump through...
  • Mark Stanger: The only possibility is to create a system property to override this in your application. Check out the...