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…
Name: Sync CI with Affected CIs
Table: Task
When: After
Insert: True
Update: True
Condition: current.cmdb_ci.changes()
Script:
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…
Name: Prevent removal/update of primary CI
Table: CIs Affected (task_ci)
When: Before
Update: True
Delete: True
Script:
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.
In the addCI() function I think the line
rec.addQuery(‘ci_item’, ci);
should be
rec.addQuery(‘ci_item’, current.cmdb_ci);
?
You’re right! I was passing that in as a parameter at one point but I removed it. Good catch.
Mark
Thanks for the article, very helpful.
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.
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.
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.
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.