Duplicates
Overview
Duplicates arise by themselves: two people create the same customer, a lead is imported twice, a company writes once from the old and once from the new address. This page finds such cases and merges them.
The order matters: find first, check second, merge third. Merging is not a trifle — it decides which record lives on and which are archived.
Core tasks
Review the suspected cases. The page separates customer duplicates from lead duplicates and names the reason for each case:
| Reason | Meaning |
|---|---|
| Same VAT ID | the strongest signal — one number belongs to exactly one company |
| Same email | the same address on two records |
| Company + domain | same company name and same internet domain |
| Same name | the weakest signal — identical names can be coincidence |
The reasons differ in strength. With same name a second look pays off; with same VAT ID the matter is usually settled.
Merge. Choose the record to be kept. The others are merged into it and archived. A confirmation names the number of affected records beforehand.
Fields in detail
This page has no form in the usual sense — it places suspected duplicates side by side and lets you pick a winner per group. It writes nonetheless, at the point where it counts: when merging.
The winner travels in the path, not in the body. You pick it with the group's radio button; it becomes the record everything is merged into. Exactly one loser is transferred per call — with three records in a group, that means twice in a row.
Merging leads and deals
| Field | Required | Values / format | What it does |
|---|---|---|---|
Loser loserUlid | yes | another lead or deal | The record that is absorbed into the winner. History, links, communication threads and sequence enrolments are re-pointed; the loser is archived afterwards and carries the reference to the winner. Winner and loser must not be the same record. |
The same action exists under the same field for deals. There is no screen for it — deal duplicates are merged through the interface, with the permission crm.deal.edit or crm.deal.delete.
Merging customers
Merging customers runs through the customer resource: there the loser sits in the field mergeLoserUlid (required, a 26-character ULID). Effect and rules are the same — a customer cannot be merged with itself, the loser is archived. The remaining fields of a customer are described on the customers page; this page changes none of them.
What else the page shows
| Item | Where from | What it means |
|---|---|---|
| Group | comparison of VAT ID, e-mail, company + domain and name | Records that might mean the same thing. A suspicion, not a decision — which is why nothing is merged on its own. |
| Reason | the rule that matched | The reasons differ in strength: the same VAT ID is the strongest, an identical name the weakest. |
| Winner | your choice per group | The record that survives. All others in the group are absorbed into it. |
This cannot be undone at the push of a button — which is why a confirmation naming the number of affected records comes first.
Settings & permissions
- Module
module.crm. - Merging requires write permissions on the kind of data concerned:
customer.mergefor
customers, crm.lead.manage for leads. Without the permission the button stays disabled instead of failing on click.
- Detection is a proposal, not a decision. The system marks suspected cases; whether it really is
the same company is decided by a person.
- The operation appears in the audit log — with the prior state.
FAQ & troubleshooting
Two obviously identical customers are not found. Then none of the four reasons applies: different spelling, no VAT ID, different email addresses and domains. Merge them by hand after aligning one of the signals — or fill in the VAT ID.
I kept the wrong record. Merging cannot be undone at the press of a button. The archived records still exist; which details were carried over is shown by the audit log. Hence the confirmation beforehand.
A lead and a customer are the same company. That is not a duplicate case but a conversion case — see Leads.
The list is empty. Then nothing suspicious was found. That is the normal state of a well-kept base.