Group Configuration Items for Easier Management in ServiceNow

//Group Configuration Items for Easier Management in ServiceNow

Group Configuration Items for Easier Management in ServiceNow

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


This customization is only offered as an update set through 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
    var newCI = cis;
    newCI.task = newTskID;

Related Links:

By | 2018-07-09T14:59:52-06:00 October 2nd, 2014|Categories: CMDB|Tags: , , |8 Comments

About the Author:


  1. simon October 29, 2014 at 8:11 am - Reply

    Hi Mark

    That is very useful. I came across this through looking for something else in connection with CMDB.
    We use CMDB to store details of what is configured at client sites, and we have a lot of things in cmdb_ci. We have a “related CI” link which is a ref to cmdb_ci on our incident form, but when a user clicks the magnifying glass, it takes a long time to load and is hard to search.
    We’d like to replace that so the user can pick only from items related to the Company referenced on the New Incident form, and also pre-filter by a limited group of CI types.
    Can you suggest the best way of doing this? Essentially to modify the CI selection dialog so the query that populates it is more specific.

    Many thanks


    • Mark Stanger October 29, 2014 at 9:37 am - Reply

      Thanks Simon. In order to filter items in any reference field, you need to use a reference qualifier. You can read more about this on the ServiceNow wiki. As for your specific reference qualifier, it might look something like this…filtering with a dependency on the ‘company’ field and also filtering for specific types.

      javascript:’company=’ + + ‘^sys_class_name=cmdb_ci_server’

  2. Corey Smith December 8, 2014 at 2:45 pm - Reply

    Hi Mark,

    I am new to this, but wondering what is the way to add the CIs to the Groups?
    Concerned if the organization has large number of CIs.

    Sorry for the dumb question.


    • Mark Stanger December 8, 2014 at 2:49 pm - Reply

      No problem Corey. You can add CIs to groups by opening up the CI group record (navigate to ‘Configuration -> Groups’ in your left nav) and then using the ‘Edit’ button on the ‘Configuration items’ related list to add any CIs you need.

  3. Bob Childress February 25, 2015 at 9:07 am - Reply

    I really liked this functionality but when I loaded it in my other Configuration Group items lost the tabs for Changes, Incidents and Problems that were linked to them – Is there anyway to not lose that information but still use this update set?

    • Mark Stanger February 25, 2015 at 9:32 am - Reply

      Sure. When you load the remote update set simply remove the form section/form layout updates before committing them to your instance.

  4. Jordan Hladish October 25, 2016 at 11:30 am - Reply

    Hi there Mark –
    I’ve stumbled on this update set I don’t know how many times now and it seems to be more and more appealing everytime I read over this page. Seems immensely beneficial for creating patching groups for situations like PRD and sub-PRD environments, but also possibly application groups, clusters, etc. Does this solution of yours have the ability to be applied with a single CI in multiple groupings? One CI could obviously be a server within DEV, as well as a part of a single application group, and a SQL cluster that we may want to group together all at the same time.

    Also, is this available for Helsinki?


    • Mark Stanger October 25, 2016 at 11:36 am - Reply

      Thanks Jordan! This works great on Helsinki and also allows for CIs to be included in as many groups as you want. You may also be interested in the Crossfuze CMDB turnkey. It includes an enhanced version of this capability that allows for the definition of CI groups based on dynamic filters so that you don’t have to manage the group membership for each individual CI. Here’s a link if you’d like to set up some time to discuss or do a demo. You can ask to speak with me directly if you’d like.

Leave A Comment