Software duplicate records experienced with SccM Service Graph Connector (SGC) in Yokohama SN

[FWilks]

We recently executed the SGC for SccM into our SN Yokohama instance.  We have another source that also creates software entries that previously existed in our tables. Instead of updating the existing record, SccM created a new software record.  We are currently using SAMPro. 

Is there a way to setup reconciliation and identification rules for the software going into the SAM Pro software tables.  Is there a de-duplication task that exists in Yokohama that can be used to identify any software duplicates?

Thanks!

[JBagby]

Have you looked into the Active Install field yet? On the Software Installations table, if the system detects duplicate installs from different sources, it should be setting Active Installation to true for one record, to indicate that as the "good" record. From that point, only the "active install" is considered for Reconciliation.

Lots of info in the Community about it if you search by the table and field, but here's one example.

[AJ-TechTrek]

Hi @FWilks ,

As per my understanding why You’re Seeing Duplicates

* SGC (Service Graph Connector for SCCM) brings software discovery data into ServiceNow CMDB/SAM tables.
* Other sources (like another discovery tool or manual inserts) are also creating software records.
* If the Identification and Reconciliation Engine (IRE) rules don’t align for those classes, ServiceNow will treat the incoming data as “new” software CIs rather than updating existing ones → duplicates.

Solutions in ServiceNow (Yokohama + SAM Pro)

1. Check & Extend Identification Rules
* Go to Identification Rules (cmdb_identification_rule.list).
* For Software Install (cmdb_ci_spkg / cmdb_ci_computer_software / cmdb_ci_spkg_instance) and Software (cmdb_software_product_model):
* Make sure the rule includes Publisher + Name + Version (SAM Pro expects this).
* If your other source only provides Name/Version (no Publisher), align the IRE mapping or create a custom identification rule.

2. Reconciliation (Precedence Rules)
* Go to Reconciliation Rules (cmdb_reconciliation_definition.list).
* Define precedence:
* Example: “If SCCM and Qualys both send software installs, SCCM wins for fields A, Qualys wins for fields B.”
* This ensures updates don’t create duplicates and also prevents unnecessary overwrites.

3. De-duplication in SAM Pro
* Out of the box, SAM Pro Normalization & Identification Engine (NIE) works to merge duplicates by:
* Normalizing Publisher + Product + Version → Software Model (cmdb_software_product_model).
* Linking all software installs (cmdb_ci_spkg_instance) to that normalized model.
However, this works only if the incoming records are identifiable via the same normalization key.

4. CMDB De-Duplication
* ServiceNow provides CMDB Data Manager → De-duplication Tasks.
* These can be scheduled against cmdb_ci_spkg_instance or related tables.
* It will suggest merges for suspected duplicates (based on attributes like Name, Version, Publisher).
* In Yokohama, this functionality exists but needs enabling from CMDB Data Manager > Deduplication definitions.

Best Practice Approach
1. Fix Identification Rules first
* Ensure SCCM + Other Source → point to the same CI (Software Install).
2. Enable Reconciliation for precedence.
3. Use SAM Pro’s Normalization to handle naming inconsistencies (e.g., “MS Office Pro Plus” vs “Microsoft Office Professional Plus”).
4. Run Deduplication (CMDB Data Manager) periodically to clean historical duplicates.

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 - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025