Introduction
Recently, while working in our production environment, we ran into an error that said a key identifier was trying to use a table that didn’t exist. This caused problems with how ServiceNow was identifying our Configuration Items (CIs), which could lead to confusion and duplicate records in our CMDB.
Because this issue can be confusing—especially for those new to ServiceNow or IT Service Management—I decided to create this simple, step-by-step guide. I’ll explain what key identifiers are, why they matter, what related entries do, and how to fix common errors like the one we faced.
Think of this as an “explain like I’m 5” guide to help everyone, from beginners to experienced admins, understand these important concepts and keep their CMDB clean and accurate.
What is a Configuration Item (CI)?
Before I jump into key identifiers, let’s understand what a Configuration Item (CI) is. Imagine your IT environment is like a big toy box. Each toy in that box is a CI — it could be a server, a network device, or an application. We want to keep track of all these toys, so we know what we have and how they relate to each other.
What is a Key Identifier? (Like a Toy’s Special Name Tag!)
Think of a key identifier as a special name tag on each toy in your toy box.
- What it is: It’s a unique label that tells you exactly which toy it is. For example, your robot toy might have a tag that says, “Robot 3000.”
- What it does: When you get a new toy, you check its tag. If you already have a toy with that tag, you know it’s the same one, maybe with a new scratch. If it’s a new tag, it’s a brand-new toy!
- What happens if it’s not there: Without these name tags, you might confuse two toys for one another or lose track of what you have. In the CMDB, this means you could have duplicate records or lose track of your assets.
How Does a Key Identifier Work?
When new data comes in from discovery tools or imports, ServiceNow looks at the key identifier attributes — like serial number or MAC address — to find if the CI already exists.
- If it finds a match, it updates the existing record.
- If not, it creates a new record.
This helps keep your CMDB accurate and prevents duplicates.
Components of a Key Identifier
- Identifier Entries: The main attributes used to identify a CI (e.g., serial number).
- Lookup Entries: Attributes found in related tables (e.g., serial number type).
- Related Entries: Extra information from related CIs that provide context but don’t directly identify the CI.
- Inclusion Rules: Conditions that limit which CIs the identifier applies to.
What Are Related Entries? (Like a Toy’s Friends or Accessories!)
Some toys have friends or accessories that go with them.
- What they are: Related entries are like the accessories or friends of a toy — for example, your “Robot 3000” might have a “Laser Gun” accessory. The laser gun isn’t the robot itself, but it belongs to it.
- What they do: They give more information about the toy but aren’t used to find the toy itself.
- What happens if they’re missing: You can still find your robot without the laser gun, but you won’t know all the cool things it can do.
Why Are Related Entries Important?
- They enrich CI data with more details.
- Help with better reporting and impact analysis.
- Support reconciliation rules to decide which data source is correct.
- Enable automation based on broader CI context.
The Real Error We Encountered
We saw this error in production:
"Rule entry under cmdb_ci_hardware identifier using non-existent table is ignored during identification."
This means one of the identifier entries was trying to use a table (cmdb_file_information) that doesn’t exist because the File-Based Discovery plugin wasn’t installed.
Because the table was missing, ServiceNow ignored that part of the identifier, which could cause some hardware CIs to be missed or duplicated.
How to Fix or Work Around This Issue
Workaround: Delete the identifier entry that references the missing table.
Permanent Fix: Install the missing plugin or upgrade to ITOM Content Service v1.5.1 or later.
Step-by-Step: Deleting the Problematic Identifier Entry
- Log in to your ServiceNow instance with admin rights.
- Navigate to:
Configuration > Identification > Identification Rules - Search for the identifier related to your CI class (e.g., cmdb_ci_hardware).
- Open the identification rule record.
- Find the Identifier Entries list.
- Locate the entry referencing the missing table (cmdb_file_information).
- Delete that entry and confirm.
- Save your changes.
- Run discovery or import to verify the error is gone and identification works.
Why Understanding Key Identifiers Matters
- Helps troubleshoot CMDB issues.
- Keeps your CMDB clean and accurate.
- Prepares you for advanced CMDB management.
- Builds a strong foundation for your ITSM career.
Summary
Key identifiers are like special name tags that help ServiceNow find and manage your CIs correctly. Related entries are like the accessories that give more info but don’t identify the CI themselves.
Errors happen when identifiers reference missing tables, but you can fix this by deleting the problematic entries or upgrading your system.
Understanding these concepts helps you keep your CMDB healthy and reliable.
Note: Many ServiceNow experts have already written extensively about key identifiers and related concepts. My intention is not to duplicate their valuable work but to share what I have personally learned through real-world experience. I hope this article will be helpful to at least one person starting their journey with ServiceNow CMDB.
If you believe the solution provided has adequately addressed your query, could you please **mark it as 'Helpful'**? This will help other community members who might have the same question find the answer more easily.
Thank you for your consideration.
Selva Arun
ServiceNow Rising Star 2024
