Duplicate table getting created after CMDB query run.

[Shraddha Dube]

Hi,

There is one scenario in which CMDB team created two tables and according to them one is original and one is duplicate with different table name and same label name.

according to CMDB team after daily query run, records used to get stored in original table which was created on 22nd May 2022 but now from last 1 month after query run records are getting stored in duplicate table like live data is now storing in duplicate table instead of Original.

When we tried to delete duplicate table and ran query, duplicate table again getting created  with same table name and again records are getting stored in that duplicate table.

Please help me to understand why duplicate table is getting generated again and again even after delete and how can we resolve this issue so records will get stored again in original table after query run.

Thank you in advance!!  

[Cindy Trieu]

Hi Shraddha,

Unfortunately without being able to take a look, I'm not sure I can provide a solution for you. I reached out to my colleague who works on Query Builder and they said the following:

"This is not a straight answer. Based on my understanding on QB , we don't create duplicate table name at all. But if customer seen one, i want to get their instance and understand what went wrong. Also we don't consider runAs field for creating table. Can they open a case task?"

If you are comfortable and this issue is important to you, please open a case task and you can let your support engineer know that they can get help from the CMDB Core Experiences team.

[AJ-TechTrek]

Hi @Shraddha Dube ,

As per my understanding why this is happening

When you say “after query run, the duplicate table gets created again” – this usually means:
* There is some integration / import / transform map / discovery pattern / data source / external script that is hardcoded to create / use the duplicate table.
* ServiceNow automatically creates a table if an import set or transform map targets a table that doesn’t exist.
For example:
* If your transform map has "Target Table" = u_duplicate_table
* Even if you delete u_duplicate_table, next time the import runs → ServiceNow recreates it because transform expects it.
* Same applies to:
* Discovery patterns
* Identification rules
* Business rules
* MID Server scripts
* Or external API integrations

Why data is going into the duplicate table
* Likely, the import set / data load process still points to the duplicate table as target.
* The original table (u_original_table) is no longer referenced.
* Or someone changed the target table of the transform map 1 month ago.

Root cause – check carefully:

1. Go to System Import Sets → Transform Maps
* Check all transform maps → look at the Target table → see if it’s the duplicate table.

2. Check Data Sources & Scheduled Imports:
* Are they targeting the duplicate table?

3. Check Discovery patterns or probes:
* If Discovery is involved, check which table is configured as target.

4. Check Business Rules / Scripts / Flows / API calls:
* Sometimes a script does new GlideRecord('u_duplicate_table').

5. Check if there is a custom table extension:
* Sometimes someone created the duplicate table as a child table with same label.

* And the process uses the child table.

How to fix - Solutions

Step 1: Identify what is creating the duplicate table
* Find out which transform map / discovery pattern / script is pointing to u_duplicate_table.
* Confirm why it is not using u_original_table.

Step 2: Correct the process
* Update the transform map or script to target u_original_table.

Step 3: Clean up
* Delete the duplicate table after ensuring nothing is pointing to it.

Step 4: Re-run data load
* Confirm that data now appears in u_original_table.

Step 5: Add controls
* Put ACLs or checks so no one can create duplicate tables.

Important check
Go to:
System Definition → Tables
Check both tables:
* Table name, label, created date, extends table, etc.
Make sure:
* The table you keep (u_original_table) is the correct parent/child,  and
* Remove the other one permanently after fixing source process.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 
Thank You
AJ - TechTrek with AJ
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
ServiceNow Community MVP 2025