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.

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.

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.

Thanks for the article, very helpful.

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

rec.addQuery(‘ci_item’, ci);

should be

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

?