Several years ago, I worked on a large ServiceNow implementation of change management. One of the key requirements on that project was to allow for the logical grouping of CIs. The primary reason for this grouping was to facilitate referencing and adding/removing these common CIs when they were all affected. This is fairly common when you’ve got a group of CIs that need the same routine maintenance or patching for example. You can imagine if you had to do this constantly for 100 different CIs how much of a pain that could become :). This capability doesn’t exist in ServiceNow and it’s actually more complex to implement than you would think but I’ve had a solution for it for quite some time.

In response to a few questions on the ServiceNow community I’ve decided to formalize this solution in an update set and publish it here on ServiceNow Guru. It allows for much simpler management and usage of these grouped CIs and can be found here in the ‘Configuration Item Groups’ update set. This has also been incorporated along with several hundred additional improvements in the Crossfuze Change Management turnkey solution. If you like this solution and are looking into change management, I highly recommend taking a look and requesting a demo!

CI Group

Usage:

This customization is only offered as an update set through ServiceNowGuru.com. You’ll need to install an update set into your instance to get this functionality. Installation and download instructions can be found below.

Administration of this solution is pretty simple. Users with the ‘ecmdb_admin’ role have the ability to manage CI groups (stored in the ‘cmdb_ci_group’ table and accessed via the ‘Configuration -> Groups’ module in the left nav). The ‘itil’ role has permission to only to view the CI groups by default but this security could be opened up using the standard ACLs in the system.

The CI group memberships are stored in a custom many-to-many table named ‘CI Group Member [u_cmdb_ci_grmember]’. These records are typically accessed via the related list on their parent group record in the CMDB.

To use the groups, simply add any CI group record as an Affected CI to any task. The ‘Add/Remove CI Group Members’ business rule on the ‘Affected CI [task_ci]’ table handles the rest!

CI Group - Added

Certain configurations separate from this solution may cause duplicate affected CIs. One of these configurations is the Change Copy routine listed here on ServiceNowGuru. In order to prevent this issue, you may need to modify your code a bit so that it doesn’t copy CIs that have been added as a part of a CI group. The ‘cis.addNullQuery’ line in the script below shows one way to approach this…

//Copy over the affected CI list
var cis = new GlideRecord('task_ci');
cis.addQuery('task', tskID);
cis.addQuery('ci_item', '!=', tskRec.cmdb_ci.toString());
cis.addNullQuery('u_ci_group'); //Added to ensure that copying does not duplicate Group CIs
cis.query();
           
while(cis.next()){
    var newCI = cis;
    newCI.task = newTskID;
    cis.insert();
}

Related Links: