Merge process

This covers the process of merging accounts in your CRM

Kernel uses the CRM APIs to perform merges and mass actions. In Salesforce, this is the SOAP Merge API. This allows us to mass-merge accounts across the CRM safely based on your custom rules and risk tolerance.

Once you have configured your rules and risk tolerance, Kernel creates merge groups. These are based on the identified duplicate groups but account for the determined risk tolerance and custom business logic. Think of the duplicate group as a truth of all the duplicates in the CRM, and the merge groups as a filtered set of those accounts that are safe to perform mass actions.

Merging

- Permanently merge duplicate records in Salesforce

- Process individual merge groups or all groups at once

- Real-time progress tracking with status updates

- Complete audit trail of all merge operations

Merge Groups

Duplicate accounts are organised into merge groups, each containing:

- Primary Account: The record that will survive the merge

- Duplicate Accounts: Secondary records to be consolidated into the primary

- Merge Status: Tracking for queued, processing, completed, or rejected merges

Merge Process

1

Discovery & Grouping

Duplicate accounts are automatically detected and grouped using Kernel's AI-driven deduplication algorithm, which analyses account data, website content, and unstructured signals across your CRM.

For more details, see Deduplication

Each merge group is assigned:

- A unique identifier

- A confidence score

- A risk tier classification

- A recommended merge decision

2

Primary record selection

Selection is determined in the following order:

1

Duplicate type priority

The type with the highest priority in the group takes precedence. Where multiple types are present, the hierarchy applied is:

Exact > Location > Regional > Trading > Website

2

Identity type

For Regional and Trading groups, the legal entity is preferred over the trading entity.

For Location groups, the parent entity is preferred over the establishment.

3

CRM field values

CRM fields configured for primary selection are compared across remaining candidates. By default, risk score and last activity date are used. The record with the highest value is preferred.

3

Field Merging

When accounts are merged, field values are consolidated using the general rule of "fill in the blanks" — when the primary record has empty fields and a duplicate has values, the duplicate's values are copied across. This is overwritten in several special cases:

1. Keep the earliest Created Date: Preserve the original creation date from the oldest record in the merge group.

2. Keep the latest Activity Date: Use the most recent activity date to reflect the latest engagement.

3. Use the newest date for other date fields: Default behaviour for date fields not covered by specific rules above.

4. Prefer active human owner: Prioritise active users over inactive/automated processes. If conflict between active owners, keep the primary record's owner.

5. 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.

6. Prevent circular references: Clear lookup fields that would create circular references (e.g., A→B when merging B into A).

7. Custom field rules: Select the value of any field in the CRM based on completeness, value, or the record it belongs to.

Custom Field Rules

Configure field-specific rules for non-standard fields:

• Always use primary: Keep primary value regardless of duplicates

• Always use newest: Select most recent value across all records

• Use longest value: Select the field with most content

• Custom logic: Apply business-specific rules

4

Related Objects

Standard Salesforce Objects

• All related standard objects (contacts, tasks, opportunities) automatically get reparented to the account.

Related Objects (Custom Objects)

• Whether the object is a custom object or another related object, with Kernel you are able to specify the logic on how you want to link them to the new primary account.

• You can select which objects should be reparented and what is the field that we need to update.

5

CRM Execution

The merge operation leverages Salesforce's native merge API:

API Constraints:

- Maximum 3 records per merge request (1 primary + 2 duplicates)

- Merge groups with more duplicates are processed in batches

- Each batch is a separate API call with retry logic

Merge Behaviour:

- Primary record retains its Salesforce ID

- Duplicate records are marked as deleted

- Related standard records (Contacts, Opportunities, Cases) are automatically reparented

- Related custom records are reparented as per the configured rules

- Field values are merged according to specified rules

- Activity history is preserved

6

Verification & Logging

After merge execution:

- System verifies duplicates are marked as deleted

- Primary record is updated with merged data

- Complete audit trail is recorded:

- Timestamp of merge operation

- User who initiated the merge

- Fields modified during merge

- Success or error status

Note: merging accounts is a destructive action. Ensure you have appropriately reviewed the data.