Deliberate duplicates
Use your business logic to preserve duplicates created for specific functions like billing or channel sales.
Not every duplicate is a mistake. Many CRMs intentionally maintain “duplicates” because the business needs separate records to support billing, channel operations, product integration, or regional ownership. Standard deduplication systems often collapse these on sight — breaking reporting, commission structures, or integrations.
Kernel protects these intentional structures by letting you define rules that preserve deliberate duplicates and prevent them from being merged.
Why deliberate duplicates exist
Below are real-world CRM patterns where duplicates are not data quality issues:
1. Billing entities
A company may have:
a corporate HQ account
multiple billing accounts for distinct contracts, divisions, or subsidiaries
separate invoice-to entities required by finance
Example: Acme Corp (HQ) Acme Corp – Billing: US Support Contract Acme Corp – Billing: EMEA Subscription
These accounts must remain separate for finance, renewal workflows, and integrations with ERP systems.
2. Channel sales & partner-delivered deals
Partners often need their own account structures that appear duplicate at the parent-company level.
Example: Cisco Cisco via Insight (Channel) Cisco via SHI (Channel)
Each “duplicate” is functionally different: attribution, compensation, and partner reporting depend on them staying separate.
3. Product-line or BU ownership
Large customers may buy several product suites handled by independent teams.
Example: GlobalBank – Retail Banking (Product Line A) GlobalBank – Commercial Banking (Product Line B)
Merging these destroys ownership boundaries, pipeline visibility, and territory models.
4. Regional autonomy
Global companies often require separate records for regional sales motions.
Example: Siemens – DACH Siemens – APAC Siemens – North America
These records look like duplicates, but they’re tied to different GTM structures, legal requirements, or regional support teams.
How Kernel handles deliberate duplicates
Kernel will identify duplicates based on our usual logic and group accounts. Kernel then evaluates your deliberate duplicate logic and intelligently excludes qualifying accounts from deduplication, ensuring nothing merges unless it should.
You can define rules based on:
Custom fields (e.g., Billing_Entity = True)
Ownership (e.g., channel partner accounts owned by the Partner Sales team)
Product line or integration (e.g., Product_Family = Cybersecurity, product_id = 1234)
Region or territory mappings
Naming conventions (e.g., “– Billing”, “(Channel)”)
Integration markers (e.g., ERP ID, Billing System ID)
When an account matches the deliberate duplicate criteria:
Kernel excludes it from auto-merge
All related deduplication and hierarchy logic respects this exclusion
This keeps critical operational structures intact while still cleaning the rest of your CRM.
Example rule sets
Billing exception
Channel partner exception
Product line split
Deliberate duplicates aren’t clutter — they’re structural. Kernel gives you fine-grained control to modernize your CRM without blowing up vital business processes. It separates the signal from the noise so your deduplication is aggressive where it should be and hands-off where it must be.Standard deduplication tools often misinterpret accounts that are intentionally duplicated for valid business reasons. Kernel prevents these incorrect merges by identifying "deliberate duplicates" based on your unique business logic.
You can configure rules to automatically exclude accounts that are separate for specific reasons, such as representing different product lines, autonomous subsidiaries, unique billing arrangements, or channel partners. When Kernel identifies an account matching this logic, it is intelligently skipped, preserving your data integrity and preventing operational disruption.
Last updated