Duplicate Record Creation Issue reported by the User
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday
Experts,
We have an issue reported by an user where a duplicate record DUPxxxxx created by his name by creation of some duplicate CIs. We are unable to find the required configuration by which the record gets created by the user's name.
If any one have ever faced such kind of issue ,Please provide your guidance for the same.
Thanks,
Sam
1 REPLY 1
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 hours ago
Hi @sam352120 ,
Duplicate CI records like "DUPxxxxx" assigned to a specific user's name in ServiceNow are typically created due to gaps in CMDB Identification Rules, manual entry processes, or discovery/source mismatches. The problem arises when ServiceNow cannot find an existing CI to update, so it creates a new one—sometimes associating the record with the creating user's name.
Weak or Missing Identification Rules: The Identification and Reconciliation Engine (IRE) relies on configured identifier attributes (e.g., serial number, name, MAC address) to decide if an incoming CI matches an existing record. If these rules are insufficient or missing data (like serial number), the engine creates a duplicate CI instead of updating the existing one, sometimes tagging the source as the person who triggered the insertion.
Manual Create/Import: A user entering or importing a CI manually may create a record that later gets duplicated when Discovery imports the same asset but cannot match it due to identifier rule mismatches.
Discovery Source Configuration: If the "discovery_source" field is set to 'Duplicate,' or an import does not properly set this field, subsequent Discovery or reconciliation processes may treat existing records as new and create duplicates.
Assignment Logic: Some transform scripts or Business Rules assign new records to the name of the creating user as the "entered_by" or "created_by" field, making it appear user-specific.
Troubleshoot
Review Identification Rules:
Go to the CI class’s Identifier configuration.
Ensure key fields like serial number, unique hostname, or other technical identifiers are marked mandatory to prevent duplicates.
Check Data Source Usage:
Avoid setting "discovery_source" to 'Duplicate' in your manual CI creation or transform imports.
Make sure no Business Rule or transform script is attributing new duplicate CIs to specific users unless by intention.
Investigate Import/Discovery Patterns:
Check if manual imports are missing primary identifiers or using inconsistent field values for matching.
For asset classes (servers, devices), check if Discovery is failing to capture an identifier and thus creates a new CI.
Clean-Up and Prevention:
Use CMDB De-Duplication tools and dashboards ("Remediate duplicate tasks") to merge, relate, or delete duplicate records as appropriate.
Reassign or migrate relationships (incidents, requests) from duplicate to master CIs before deleting unnecessary records.
Regularly audit incoming data, update identifier rules, and train users to avoid creating manual entries without key attributes.
Best Practice
Identification rules must match your real-world IT landscape (e.g., serial numbers, asset tags, hostnames).
Prevent manual CI creation unless mandatory identifier fields are provided.
Monitor the CMDB for "DUPxxxxx" or similar tags and use built-in deduplication workflows to manage.
If duplication persists, focus on strengthening your identification rules and review transform maps, import sets, and user entry forms for configuration that might assign ownership inappropriately.
Please refer to the below link:-
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0869861
https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0695124
https://www.servicenow.com/community/in-other-news/duplicate-configuration-items-in-the-servicenow-c...
