What are CI Identification Rules?
CI Identification Rules are a set of criteria that ServiceNow uses to uniquely identify and differentiate Configuration Items (CIs) within the CMDB. These rules play a vital role in preventing duplication and ensuring the accuracy and integrity of the data stored in the CMDB. They define how a Configuration Item (CI) is identified based on its unique attributes, such as Serial Number, Name, Device ID, Object ID, etc. or any combination of such attributes which act as unique identifiers for a particular CI type.
CI identification rules in action
When a new CI is introduced into the CMDB, ServiceNow's identification and reconciliation engine (IRE) checks the defined CI Identification Rules for a particular CI class to determine whether it is a new CI or if it matches an existing CI. If a match is found based on the identification rules, ServiceNow updates the existing CI record with the new information. However, if no match is found, a new CI record is created within the appropriate CI class. The identification rules for a CI class can be accessed as follows:
- Go to CI Class Manager
- Open the CI class for which you would like to check the identification rules (E.g. Computer, Server, Network Gear etc.)
- Click on the ‘Identification rule’ tab. The criteria defined under the heading ‘Identifier entries’ indicate the ‘Identification rule’
Note: The identifier entries can also be accessed directly in a list view from the application navigator by going to Configuration>Identification/Reconciliation>CI identifiers
Let’s consider an example to illustrate ‘Identification rules’. The following screenshot shows the out-of-the-box (OOB) identifier entries for Computer CI class (table name is ‘cmdb_ci_computer’), which represents computer devices in the CMDB.
Here you can see ‘Priority’ values assigned for each identifier entry. The entry with the lowest value of ‘Priority’ (i.e., 100 in this screenshot) would be checked first, followed by the remaining 3 entries based on ‘Priority’. So in this example, for each record, ServiceNow will check for presence of existing CIs with the combination of ‘Serial Number’ and ‘Serial Number Type’ first. If a match is found, the existing CI will be updated, and the remaining identifier entries won’t be evaluated. If a match is not found, it will proceed to evaluate the next identifier entry (only Serial Number) and so on. If a match is not found after evaluating all the 4 identifier entries, a new record will be created.
Note: Identifier entries won’t be considered by CMDB data population methods that do NOT go through the identification and reconciliation engine (IRE), like 3rd party data source integrations which are NOT done using Service Graph connectors and manual data population which is done WITHOUT using Integration Hub ETL. Hence it is recommended to use Service Graph Connectors (if available) for 3rd party tool integrations to populate the CMDB and Integration hub ETL for manual CMDB data import.
Identification inclusion rules
This is an additional feature available to narrow the scope of CIs that are included in the identification process. When identification inclusion rule is defined for a CI class, ServiceNow’s Identification and Reconciliation Engine (IRE) processes only the Configuration Items (CIs) that meet the criteria set by the identification inclusion rules during the duplication detection of independent CIs. For example, you can create a rule to include solely the CIs whose ‘Operational Status’ is ‘Operational’. These rules are defined at the individual class level for each CI class. There are no predefined inclusion rules in an out-of-the-box(OOB) ServiceNow instance. When no inclusion rules exist for a CI class, all CIs of that class are subject to the identification process and CMDB Health duplicate metric calculations.
The inclusion rules can also be created from the same ‘Identification rule’ tab of a CI class from the CI class manager. You can find ‘Inclusion Rule (Advanced)’ under the Identifier entries. Click on ‘Add’ and then define the ‘Active record condition’ . For example, the following screenshot shows how to set an inclusion rule for ‘Computer’ CI class with the condition Operation status=Operational.
Defining Effective CI Identification Rules
Defining effective CI Identification Rules is crucial for maintaining an accurate and reliable CMDB. It is recommended to review the identifier entries for all the CI classes which you plan to populate and ensure that the selected set of attributes act as unique identifiers for each CI class. Sometimes the OOB identifier entries itself might be sufficient and sometimes modifications might be required.
Some of the key considerations for defining CI Identification Rules are given below:
- Choose unique attributes: Select attributes that are guaranteed to be unique for each instance of the CI class. Common examples include Serial number, Name, Device ID etc.
- Consider attribute reliability: Ensure that the chosen attributes are consistently available and reliable throughout the CI lifecycle. Attributes that are prone to change or those which are less likely to be present for all records of a CI class should be avoided.
- Leverage multiple attributes: As we saw earlier in the example of ‘Computer’ CI class, consider combining multiple attributes to create the identification rule. This is especially necessary when the unique attributes might vary based on the data sources used for populating a CI class.
- Review and update regularly: As your IT infrastructure evolves, periodically review and update the CI Identification Rules to align with changes in your CI classes (E.g. addition of a new data source) and attribute availability.
Conclusion
Properly defined CI Identification rules are pivotal for maintaining an accurate and trustworthy CMDB. By defining clear rules using unique, reliable, and consistent attributes, organizations can ensure that their IT infrastructure is accurately represented throughout its lifecycle, unlocking benefits such as effective IT service management, enhanced IT asset management, mitigation of security and compliance risks, cost optimization through streamlined operations, better decision-making aligned with business objectives, etc.
