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!
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!
- Download: Configuration Item Groups
- Supporting Documentation: Installing an update set on your instance
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.
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.
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.
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.
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?
Sure. When you load the remote update set simply remove the form section/form layout updates before committing them to your instance.
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?
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.