Merge duplicates
How Kernel merges duplicate accounts in Salesforce
Kernel can merge duplicate Salesforce accounts in bulk without blindly collapsing records that should stay separate.
The workflow is simple:
Kernel finds likely duplicate accounts.
You define which duplicates are safe to merge.
Kernel groups those records into merge groups.
Kernel merges them using Salesforce's native merge API.
Kernel logs what happened.
A duplicate group is the full set of records that look related. A merge group is the subset Kernel considers safe to act on after applying your rules.
What a merge group contains
Each merge group has:
one primary account, which survives the merge
one or more duplicate accounts, which are merged into the primary
a status, such as queued, processing, completed, or rejected
How Kernel finds duplicates
Kernel scans your CRM and builds candidate duplicate groups using account data and other signals.
For each group, Kernel assigns:
a group ID
a confidence score
a duplicate type
a recommended primary record
Choosing the primary record
Each duplicate group has one primary account.
The primary is the record that keeps its Salesforce ID after the merge. The other records are merged into it.
Kernel can choose the primary record using configurable rules. For example, you may prefer the record with:
the most complete data
the active owner
the newest activity
a trusted source system
a specific account type or region
How field values are merged
By default, Kernel uses a "fill in the blanks" approach.
That means if the primary record has an empty field and a duplicate record has a value, Kernel copies that value to the primary.
You can override this with field-level rules.
Common options include:
always keep the primary value
always use the newest value
use the longest value
prefer values from a trusted source
apply custom logic for specific fields
Related records
Standard Salesforce objects
Salesforce automatically reparents standard related records during a merge. This includes objects like contacts, tasks, opportunities, and cases.
Custom objects
For custom objects, Kernel lets you define:
which objects should be reparented
which lookup field should be updated
any special rules for handling those links
How merge execution works
Kernel uses Salesforce's native merge API.
Important Salesforce limit:
each merge request can include at most 3 records: 1 primary and 2 duplicates
If a merge group has more than 3 records, Kernel processes it in batches.
During execution:
the primary record keeps its Salesforce ID
duplicate records are deleted by Salesforce as part of the merge
standard related records are reparented automatically
custom related records are reparented based on your configuration
field values are updated using your survivorship rules
Deliberate duplicates
Not every duplicate should be merged.
Many companies keep similar-looking account records on purpose. These records may support billing, channel sales, product ownership, regional operations, or integrations.
Examples:
separate billing entities
channel-specific account records
different business units under the same parent
regional account records for global companies
Kernel lets you define rules to preserve these deliberate duplicates.
If a record matches those rules, Kernel excludes it from merge actions.
You can define exclusions using:
custom fields
owner or team
account type
product line
region or territory
naming patterns
source system or external IDs
Example exclusion rules
Billing entities:
Channel accounts:
Product-line splits:
Audit trail and verification
After each merge, Kernel records:
when the merge ran
who initiated it
which records were merged
which fields changed
whether the merge succeeded or failed
Kernel also verifies that the merge completed as expected.
What you control
You control three things:
which duplicate groups are allowed to merge
which data survives the merge
That gives you a way to clean up CRM duplicates without breaking account ownership, billing structure, reporting, or downstream integrations.
Last updated