_
_
Back to Blog

Making ServiceNow CMDB Health Inclusion Rules Dynamic

Enhancing Flexibility with CMDB Inclusion Criteria
3
min read
|
by
Jake McKenna
February 12, 2025

ServiceNow’s Configuration Management Database (CMDB) plays a critical role in ensuring that IT infrastructure components are properly tracked, managed, and maintained. One key feature that enhances the functionality of the CMDB is CMDB Health—which includes data accuracy, completeness, and compliance indicators. To ensure optimal health of your CMDB, Inclusion Rules are used to define which configuration items (CIs) are considered in the health assessment.

However, manually configuring Inclusion Rules for specific CI classes can be a tedious and static process. To overcome this limitation, you can make your CMDB Health Inclusion Rules dynamic by leveraging Inclusion Rules based on Principal Classes. This method ensures the rules adapt automatically to changes in the environment or CI structure.

What Are Inclusion Rules?

Inclusion Rules are used to define the scope of configuration items that should be considered in CMDB Health checks. By default, the scope of Inclusion Rules is static, meaning they are hardcoded for specific CI classes. If you add new CIs or create custom classes, the static rule needs to be manually updated.

Making Inclusion Rules Dynamic

Here’s a step-by-step guide to make Inclusion Rules dynamic using an Advanced Reference Qualifier based on Principal Classes.

1. Identify Principal Classes

Principal classes in ServiceNow are typically high-level classes like cmdb_ci_computer, cmdb_ci_appl, cmdb_ci_database, and so on. These are often parent classes, and their child classes inherit properties and attributes from them. We want to leverage this hierarchy to dynamically include all children of a principal class.

2. Create a Dynamic Inclusion Rule

To apply a Dynamic Inclusion Rule, you will need to create a script that populates the condition field..

Here’s a sample script for an Dynamic Inclusion Rule Qualifier:



(function makeRules(){
   var metric = 'Staleness'; //Staleness, Orphan, Recommended, Required, Duplicate
   var filterAdd = 'operational_status=1'; //principal class is already planned
   var ciTable = 'cmdb_ci';
   var answer = createRule(metric, filterAdd, ciTable);
   gs.debug('The metric rule was ' + answer + ' for the table ' + ciTable);
})();
function createRule(metric, filterAdd, ciTable){
   var q = 'sys_class_nameINjavascript:new PrincipalClass().getPrincipalClasses()'
   var metricId = getMetric(metric);
   if(filterAdd){
       q += '^' + filterAdd;
   }
   if(!metricId){
       gs.debug('Failed to lookup metric id. Check the name sent.');
       return;
   }
   var gr = new GlideRecord('cmdb_health_config');
   gr.addQuery('applies_to', ciTable);
   gr.addQuery('metric', metricId);
   gr.query();
   if(gr.next()){
       gr.active_record_condition = q;
       gr.update();
       return 'updated';
   } else {
       gr.initialize();
       gr.metric = metricId;
       gr.active_record_condition = q;
       gr.applies_to = ciTable;
       gr.insert();
       return 'inserted';
   }
}
function getMetric(name) {
   var gr = new GlideRecord('cmdb_health_metric');
   gr.addQuery('name', name);
   gr.addEncodedQuery('parent!=2de886a2cb101200cab07f1b734c9cb2');
   gr.query();
   if(gr.next()) {
       return gr.getValue('sys_id');
   }
   return '';
}

The script dynamically creates or updates a CMDB Health metric rule in ServiceNow, targeting CIs based on the principal class and applying additional filters. It ensures the rule is applied to the specified CI table and uses the provided metric to configure the rule’s condition.

  • makeRules Function:
    • It defines variables for the metric (set to "Staleness"), an additional filter (operational_status=1), and the table (set to cmdb_ci).
    • Calls the createRule function with these parameters and logs whether the rule was created or updated.
  • createRule Function:
    • Builds a query (q) to include Principal Classes (high-level CI classes) and any additional filters (filterAdd).
    • Retrieves the metric ID for the given metric using the getMetric function.
    • Checks the cmdb_health_config table for existing rules for the given metric and CI table.
      1. If a rule exists, it updates the condition.
      2. If not, it creates a new rule.
  • getMetric Function:
    • Queries the cmdb_health_metric table to retrieve the sys_id of the specified metric, excluding those with a specific parent value.

3. Apply the CMDB Qualifier

To apply this script:

  • You will need the admin role.
  • Navigate to the Background - Scripts
  • Paste the above script into the Script and Run it. 
  • Navigate to your CI Class Manager
  • Validate you see the Inclusion rules for your class the rule applied to

Benefits of Dynamic Inclusion Rules

  1. Scalability: As the environment grows, the system automatically adapts to new CI classes without manual updates.
  2. Accuracy: Inclusion Rules remain up-to-date with the latest CI structures, ensuring the health checks are always accurate.
  3. Efficiency: Reduces the administrative burden of maintaining CMDB Health rules.

Conclusion

Leveraging ServiceNow to create Dynamic Inclusion Rules for CMDB Health is a powerful way to manage a complex and evolving IT environment. By automating the inclusion of classes based on principal class hierarchies, you enhance the accuracy, efficiency, and scalability of your CMDB Health process, ensuring your IT assets are always aligned with the organization’s needs.

Interested to learn more? Reach out to chat@rapdev.io

Written by
Jake McKenna
Michigan
A seasoned ServiceNow expert hailing from Linden, Michigan. When not optimizing workflows and enhancing user experiences, you can find them unwinding amidst the tranquil beauty of Northern Michigan on weekends, embracing the serene landscapes and outdoor adventures it offers. Passionate about both their professional craft and their leisure pursuits, they strike a harmonious balance between technology and nature.
you might also like
back to blog