Duplicates on core_company table <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Issue Summary Duplicate records were being created in the core_company table, resulting in data integrity issues across the instance. Company records that should have been matched to existing entries were instead being inserted as new records. This behavior is controlled by the canonical_hash field, which is used by the platform to identify and deduplicate company records during import, sync, and creation operations. The unique index on this field was missing or had been dropped, removing the enforcement mechanism that prevents duplicate entries. Symptoms Duplicate company records appearing in core_company after data imports or sync operationsCompany matching logic failing to resolve existing records — new records created insteadReference fields on related tables (e.g., contacts, accounts, tasks) pointing to inconsistent company entriesPotential visible duplication in Company lookups within the UI Root Cause The unique index on the canonical_hash column of the core_company table was absent. This index is responsible for enforcing uniqueness at the database level, preventing two records from sharing the same canonical hash value. Without this index, the platform's deduplication logic could not rely on a uniqueness constraint, allowing duplicate records to be persisted whenever a company was created or synced without a prior match. The index may have been dropped intentionally or inadvertently during a prior maintenance operation, migration, or cleanup effort on the instance. Solution Repairing the Normalization Data Services Client plugin should help restore the OOTB index for the canonical hashes for core_company to help prevent the insertion of duplicates, even if the duplicates are created with the same hash.