When two contact records in the CRM obviously describe the same person or company, the question arises: which one stays, which one goes – and what happens to the fields in which the two differ? 1Tool answers this question with a clear technical concept: each affected field is individually assigned one of two states, SURVIVOR or DUPLICATE. This article explains how this mechanism works in detail and why it deliberately does not use automatic winner logic.
The principle: SURVIVOR and DUPLICATE per field
Instead of declaring an entire record the winner, duplicate detection in 1Tool works at field level. For each relevant field – such as phone number, email address or postal address – it is marked separately which of the two records the value should be taken from. The value that is kept has the status Survivor, the discarded value the status Duplicate. At the end of the merge, the result is a single contact whose fields can come from both original records – depending on which record held the more accurate information where.
Why the newer or more complete record does not simply win
It would be technically easy to implement a rule that automatically prefers, say, the most recently edited record or the one with the most filled-in fields. In practice, however, such rules regularly get it wrong. A typical example: a contact was recently updated with a new, correct mobile number – but the same record still contains an outdated company address from a previous move. The second, older record, on the other hand, never received the new phone number but does hold the correct, current company address. An automatic newest-wins rule would discard the correct address. A most-complete-wins rule could be just as wrong if the supposedly more complete record simply contains more fields, some of them outdated. Such constellations are not edge cases; in contact databases that have grown over time, they are the norm: different employees maintain different fields at different times. That is exactly why 1Tool leaves the survivor decision to the user rather than to a rigid algorithm.
A traceable process
In practice, this means: when two contacts identified as duplicates are merged, the differing field values are shown side by side. For each field in which the records differ, SURVIVOR or DUPLICATE is assigned deliberately. If two fields match anyway, no decision is needed. The result is a merge that requires more attention than a single click on Merge, but prevents valuable, correct information from being discarded by mistake.
Frequently asked questions
Does SURVIVOR or DUPLICATE apply to the whole contact or to individual fields?
To individual fields. Each field, such as phone number, email or address, is assessed separately.
Does the system automatically pick a favourite that I just have to confirm?
The decision as to which value counts as the survivor for each field is yours – there is no automatic prioritisation by age or completeness.
What if the two records do not differ at all in a field?
Then no decision is needed, because the same value ends up in the merged contact anyway.
How often have you relied on an automatic merge – and how sure were you really?