Find and merge duplicate contacts

Duplicate people are normal in a CRM: the same person arrives from a company register, from a spreadsheet and from your accounting system, and each route creates its own record. DealJourney looks for them and offers them to you grouped, from Review duplicates on the Contacts page.

Nothing is ever merged for you. These are suggestions and can be wrong — you decide what gets merged. The scan only groups and explains; you pick what happens.

What is actually compared

The name is what makes two records candidates. First and last name are joined, capitalisation is ignored and repeated spaces are collapsed, and only records whose result is identical are ever compared. Two records with the same email address but differently spelled names are not offered as a pair.

This is the single most useful thing to know about the check: it will not find "Jon Hansen" and "John Hansen", and no amount of matching email addresses will make it. Those you find by searching.

Within a name, records are grouped by what they really share:

• Same email address, compared ignoring capitalisation and surrounding spaces. The strongest signal there is.
• Same phone number, checked across both work and mobile numbers, ignoring spaces and dashes. An international prefix written with + or 00 counts as the same prefix. Different country codes remain different numbers. A number without a country code is not assumed to match an international number: the records still appear as a name match, but the ambiguous number does not make them a strong match. Numbers shorter than seven digits are ignored rather than guessed at.
• Linked to the same company, between records linked to one company.

Records join a group through one of those, directly or through each other. Ten people called Henrik Nielsen, two of whom share an email address, become one group of two, not one group of ten. The ones that share nothing but the name are offered in a group of their own. A blank field is never a match: two records with no email are not "the same email".

Every group spells out why it exists under Why these are grouped: the name, each shared email address, phone number or company, and how many of the records share it. The matching details are also marked on each record, so you can see who shares what without opening anyone.

Review the match, then compare

The filters describe why records match, not whether merging is safe:

• Email or phone match: every record shares an email or phone number with another record in its group.
• Company connection: company connections join the records, including groups where only some share an email or phone.
• Name only: only the name matches.

The review counts all groups and loads them a page at a time. Matching details are evidence, not a probability or a guarantee that these are the same person.

Open Compare contacts on a group. Contacts appear in fixed columns, labelled by their position so records with the same name can be distinguished without exposing internal identifiers. The comparison shows email, the phone shown in the match, job title, companies and roles, and creation date. A contact may have other phone numbers which this summary does not show.

Different values marks different populated values among included contacts. Some details missing means some included contacts lack that detail. Neither label assesses the whole record.

Choose the contacts and the survivor

Use Include in the merge to include or exclude each contact. Excluded contacts are marked Left alone and remain unchanged. Email or phone match groups initially include matching contacts; other groups initially include only the suggested survivor. A record marked Only the name matches starts excluded.

Use Keep this one to choose the survivor, marked Contact to keep. Columns do not move when you change this choice. The initial suggestion prioritizes email, then phone, then company links and age; it does not measure completeness of notes, history or custom fields. Excluding the survivor moves the choice to another included contact.

The arrow beneath the comparison shows the included source contacts pointing into the survivor, with the number that will be removed. Include at least two contacts before choosing Review merge.

Confirm the removal

The confirmation lists the survivor and each contact that will be removed. The survivor keeps its existing contact ID. Removed contacts are deleted; their IDs are not redirected to the survivor. There is no undo in the product.

Existing values on the survivor win. Supported empty fields can be filled from the other contacts, but different populated values are not retained as alternatives. Individual field choices are not available in this comparison.

The comparison does not check the entire contact. Notes, events, files, custom fields, permissions and accounting links have not been compared for conflicts or loss. Existing merge handling moves supported relationships, but it does not guarantee preservation of every related record or detail. Review those records separately before proceeding, or leave the group unchanged and contact support if unsure. See Add a contact to a company for company relationships.

Confirm that these are the same person and acknowledge the possible loss and irreversibility before submitting. Back to comparison returns to the comparison without merging. A successful merge refreshes the review so remaining contacts and inherited values are checked again.

If the merge result cannot be confirmed, the old comparison is closed because the records may already have changed. Try again runs a fresh scan; it does not repeat the merge. A rejected request keeps your choices available for review.

Bulk merging is unavailable until all contact data can be checked for safe preservation. Matching basic details alone never enables bulk merging.

Contacts that arrive from Tripletex or another ERP

A contact pulled in from an accounting system is matched only on the link stored the first time that person was synced — not on their email address and not on their name. That has one consequence worth understanding:

• A person you already had in DealJourney, who has never been synced, arrives as a second record. The pull does not look for them by email first. This is the main way ERP duplicates appear, and finding them afterwards is what the duplicate review is for.
• Once linked, later runs update that same record instead of adding another.
• A contact with no company on the accounting side is skipped rather than created without one.

Going the other way — sending one of your contacts to the accounting system — does check first: within the same company it looks for a contact with the same email address, and failing that the same first and last name, and links to that one instead of creating a duplicate over there.

Merging here changes DealJourney only. The accounting system still holds both people, and the record you merged away keeps its link to a person that no longer exists on this side. Tidy the duplicate in the accounting system too, rather than only here. General background on these connections is in Accounting and ERP integrations.

Duplicates from a spreadsheet import

That is a different cause with a different fix — an import can update the records you already hold instead of adding new ones. See Avoid creating duplicates.