Merging logic
Use intelligent logic to select the primary record and preserve your most valuable data during a merge.
Primary record
In a group of duplicates, the primary record is selected using the following logic:
Selection is determined in the following order:
In a group of three duplicates, only one primary account can exist. Once the merge is complete, the two non-primary records will be functionally deleted.
Survivorship logic
Kernel allows the user to configure the primary approach for handling conflicting data during merges.
In the example below, the account on the left has been determined as the Primary record, but is currently unassigned. One of the duplicate records contains an active owner as defined in thehttps://github.com/generatemomentum/documentation/blob/main/legacy/configuration/active-users.md. A regular merge would effectively remove this account from the owner's books.
To prevent this, Kernel first transfers the active owner to the primary account before completing the merge.
Kernel has preconfigured options for setting the survivorship logic. We can also look at specific values on an account to create custom logic based on field values on accounts being considered for merge.
Default survivorship logic
Kernel provides an opinionated configuration for account merging. The general rule is to "fill in the blanks", i.e., when Record A has empty fields and Record B has values, copy B's values to A. For example, if A has no phone number but B does, keep B's phone number in the merged record.
However, this is overwritten in several special cases:
Keep the earliest Created Date: Preserve the original creation date from the oldest record in the merge group.
Keep the latest Activity Date: Use the most recent activity date to reflect the latest engagement.
Use the newest date for other date fields: Default behaviour for date fields not covered by specific rules above.
Prefer active human owner: Prioritise active users over inactive/automated processes. If conflict between active owners, keep the primary record's owner.
Preserve complete addresses: When merging records with conflicting address data, choose the record with all 4 components: Street + City + State/Province + Postal Code. If both records are equally complete, fall back to standard "fill in the blanks" behaviour.
Prevent circular references: Clear lookup fields that would create circular references (e.g., A→B when merging B into A).
Custom field rules: Select the value of any field in the CRM based on completeness, value, or the record it belongs to.
Account survivorship
Kernel allows you to control exactly which values survive a merge by applying rules that depend on the data present inside the duplicate group. Instead of blindly copying values from the Primary record, Kernel evaluates fields using conditions you define — giving you precise control over the outcome.
Based on these conditions you can adjust the data that survives from an account within a group.
Example 1: Keep Product-specific data only when a Product ID exists.
Useful when product accounts have much better data.
Conditions
Duplicate.Product_ID is not empty
Action
Use fields from the product account post merge.
Example 3 — Keep fields from records created through integrations
Use case: ERP/Billing sources should override CRM-derived values.
Conditions
Duplicate.Source_System = “ERP” OR “Billing”
Field on ERP record is not empty
Action
Always take those fields from the ERP/Billing record (examples: ERP_ID, Billing_Account_ID, Tax_Status, Payment_Terms)
Last updated