Identification rules
Summarize
Summary of Identification rules
Identification rules in the CMDB enable the unique identification of Configuration Items (CIs) by using specific attribute sets and relationships. These rules apply to CI classes, consisting of a CI identifier with identifier entries and related entries prioritized to ensure strong identification. Properly configured identification rules are essential for accurate CMDB reconciliation and maintaining data integrity.
Show less
Key Features
- Identification Rules Structure: Each rule applies to a CI class and includes a unique CI identifier, with multiple identifier entries and related entries prioritized for effective identification.
- Unique and Required Attributes: Identification relies on unique attributes that can be from the same or derived tables, and required attributes that must not be empty.
- Inheritance of Rules: Child CI classes inherit identification rules from parent classes unless an explicit rule is defined, which then overrides the inherited rule.
- Independent vs Dependent CIs: Independent CIs are identified based on their own attributes, while dependent CIs require identifying their parent CI first, reflecting their dependency relationships.
- Identifier Entries Types:
- Regular identifier entries use the CI’s own fields.
- Lookup identifier entries use related tables referencing the CI table (cmdbci) for identification.
- Hybrid entries combine both regular and lookup methods to handle complex cases.
- Guidelines for Lookup Tables: Ensure lookup tables reference cmdbci, enforce exact count match for stronger rules, and avoid conflicting identification rules that may cause duplicates.
- Related Entries: Rules based on related tables allow creation or updates of associated records but are not directly used for CI identification.
- Identification Inclusion Rules: These rules narrow the scope of CIs included in the identification process to optimize performance and accuracy.
Practical Application for ServiceNow Customers
As a ServiceNow customer managing the CMDB, use identification rules to ensure each CI is uniquely and accurately identified during discovery and reconciliation processes. Configure strong identifier entries with appropriate priorities and leverage inheritance to streamline rule management across class hierarchies. Differentiate between independent and dependent CIs to correctly model dependencies and avoid reconciliation errors.
Use lookup and hybrid identifier entries strategically when CI attributes alone are insufficient, especially in complex environments such as virtual machines with overlapping attribute values. Carefully define related entries to maintain associated data integrity without impacting CI uniqueness. Apply identification inclusion rules to focus discovery on relevant CI subsets, improving efficiency.
Following these guidelines helps maintain a reliable, consistent CMDB that supports accurate service management and operational decision-making.
The CMDB identification process relies on identification rules to uniquely identify CIs.
An identification rule applies to a CI class and consists of a single CI identifier and one or more identifier entries and related entries, each with a different priority. Each identifier entry defines a unique attribute set with a specific priority and each related entry defines rules for identifying related items. Create strong identification rules that are set with the highest priority for the strongest identifier entries and related entries.
- Unique attributes
- Designated sets of criterion attribute values of a CI that can be used to uniquely identify the CI. Unique attributes can be from the same table or from derived tables.
- Required attributes
- Designated attributes of a CI that cannot be empty.
Derivation across the CMDB hierarchy
If no identification rule is explicitly defined for a child class, then the child class derives its identification rule, including any associated identification entries and related entries, from its parent class. Later, an own identification rule can be explicitly defined for the child class. In that case, the identification rule that was initially derived from the parent class, including any associated identification entries and related entries, is no longer in effect at the child class. Also, you must explicitly add identification entries and related entries in the newly created identification rule at the child class.
For example: The Hardware class identification rule has a related entry for the Software Instance table. This identification rule, including its associated related entry for the Software Instance table, is derived by the Computer class. If you then create a new identification rule for the Computer class, it overwrites the identification rule that was derived from the Hardware class. Therefore, the Hardware class identification rule, including its associated related entry for the Software Instance table, is no longer in effect for the Computer class. If the same related entry is needed, you must explicitly add a related entry for the Software Instance table in the newly created identification rule for the Computer class.
Identification rule types
- Independent CIs
- CIs, such as Server CIs, which exist on their own and are not dependent on any other CIs.
- Dependent CIs
- CIs which depend on a relationship to another CI and can't exist on their own in the
absence of the dependent relationship. For example:
- Network Adapter CIs can't exist meaningfully without the Hardware CIs that contain them.
- Application CIs can't exist on their own without the Server CI they are hosted on.
- Independent identification rule
- A rule that identifies a CI based on the CI's own attributes, independently of other CIs or relationship.
- Dependent identification rule
- A rule in which identifying a CI requires identifying a dependent CI first. A CI can
have dependency on one or more CIs, and a dependent CI can have only a single parent
CI with dependency. The relationship types between the CI and its dependent CIs are
also included in the identification process. To help with the identification process
of dependent CIs, create dependent
relationships that define the dependency chain within CI types.
The payload used for identification of a dependent CI, can include a relationship with a qualifier chain. For such relationship, if there is a matching parent/child pair, the system compares the qualifier chain in the payload, with the qualifier chain of the CIs in the database. If there is a difference, the qualifier chain in the database is updated to match the qualifier chain in the payload for that relationship.
Identifier entries
You can configure an identifier entry to match a CI not only based on the CI's own attributes (field-based identification) but also based on the CI's related list (lookup-based identification) such as Serial Numbers or Network Adapters. The lookup table that is used for identification, needs to have a reference field that points to cmdb_ci.
- Regular identifier entry
- Identification is based on CI's own attributes that uniquely identify the CI.
- Lookup identifier entry
Identification uses a lookup table (related table) which can be any table that has a reference to the CI that is being identified. After you select a related lookup table, you select identifier attributes from the related table that reference either the cmdb_ci table itself, or one of its descendants.
If the lookup records don't already exist, then they are inserted in the lookup table referenced in the identifier entry.
- Hybrid identifier entry
- A combination of both, a regular identifier entry and a lookup identifier entry.
Example: When discovering virtual machines in a cloud environment which might contain two virtual machines with an identical set of serial numbers. A lookup identifier entry for the Hardware table such as [Table: Serial Number, Criterion Attributes: Serial Number, Serial Number Type] cannot uniquely identify these two virtual machines. However, a hybrid identifier entry such as [Table: Serial Number, Criterion Attributes: Serial Number, Serial Number Type + (Name field from main Hardware table)] can uniquely identify the two virtual machines.
Guidelines for lookup tables
- Ensure that lookup tables reference the cmdb_ci table.
- It is preferable to enforce exact count match (check box Enforce exact count match (Lookup)) for a stronger identification rule. During lookup identification, this option enforces matching only on exact lookup records count match. See Create a CI identification rule for more details.
- Do not create conflicting identification rules especially for lookup-based rule.
Example: In a CI Identifier for the Hardware class, you specify a lookup-based rule for the Network Adapter class and you also define a CI Identifier for the Network Adapter class. Duplicates might potentially be created in the Network Adapter table, because there are contradicting rules to identify a unique CI in that table:
- One rule that looks only at criterion attributes (CI identifier rule)
- Another rule that looks at criterion attributes and referenced sys_id (lookup rule).
var payload = {
items: [{
className:'cmdb_ci_linux_server',
related: [{
className:'cmdb_ci_spkg',
values: {
name:'package1',
version:'version1'
}
}],
values: {
sys_id:'194876usytrr65378098'
}
}]
};Related entries
You can define related entries which are rules that are based on related CIs. A related entry is based on a related table which can be any table (CMDB or non-CMDB) that has a reference to the CI that is being identified. Related entries let you create or update records on other tables in which the data is associated with the CI being identified by the identifier entries. Related entries are not used to directly identify CIs.
After you select a related table for the rule, the list in Referenced field is populated with fields from the related table that reference either the cmdb_ci table itself, or one of its descendants.
A related entry for a class is derived by child classes for which no related entries are specified.