Dedupely Intelligence
TL;DR
- Duplicates often disagree on dates, and each date field needs its own answer.
- Dates that mark a beginning, like first contact or customer since, should keep the earliest value.
- Dates that mark the latest state, like last activity or last purchase, should keep the newest.
- System dates, like created date, usually can't be changed, so the surviving record's value stays.
- In Dedupely, you pick the surviving record and set rules per field, like "Newest wins" on a date.
Two duplicates almost never agree on their dates. One was created in 2021, the other last month. One shows a last activity yesterday, the other a year ago. One says the customer has been a customer since 2019, the other since 2023.
A merge keeps one value per field. Which one is right depends on what the date means. This post covers how to decide, field by field.
Two kinds of dates
Beginning dates mark when something started: first contact, first purchase, customer since, original lead date. The earliest value is usually right, because the duplicate was created later and doesn't know the history.
Latest-state dates mark the most recent event: last activity, last purchase, last email opened. The newest value is usually right, because it reflects what happened most recently.
Field by field
| Date field | Usually keep | Why |
|---|---|---|
| Created date | The surviving record's | Set by the CRM; often can't be edited |
| First contact or original source date | Earliest | The first record knows when it really started |
| Customer since | Earliest | A duplicate created later resets the history |
| Last activity | Newest | Shows the most recent touch |
| Last purchase or order | Newest | Shows the latest buying date |
| Next renewal or follow-up | Check by hand | Two different future dates may both be wrong |
| Birthday or anniversary | Check by hand | Only one can be right |
Created date and other system dates
Most CRMs set the created date themselves and don't let you edit it. After a merge, the merged record shows the created date of the record that survived. If the earliest created date matters to you, make the oldest record the one that survives.
Other system fields, like last modified, change on their own and don't need a rule.
When dates need a person
Future dates are the risky ones. Two different renewal dates or follow-up dates might mean two contracts, or a mistake on one record. Before a bulk merge, check sets where a renewal or contract date differs, or leave that field to the owner to fix.
How Dedupely handles dates
In Dedupely, the Primary Record setting decides which record survives, with options like Oldest Record, which keeps the original record and its created date. Field-level Merge Rules then decide each field separately: the suggested rule "Newest wins" keeps the latest date in fields like last activity, and "From the most recently worked record" takes values from the record someone worked on last. Blank values never win, so a date on one record isn't replaced by an empty field on the other. A preview shows the merge result while you build the rules.
Each date has its own answer
Beginning dates keep the earliest value, latest-state dates keep the newest, system dates follow the surviving record, and future dates that disagree need a person. Set a rule for each date field that matters before you merge in bulk.
Frequently asked questions
Which date should win when merging duplicate records?
It depends on the field. Keep the earliest value for beginning dates like customer since, and the newest for latest-state dates like last activity.
What happens to the created date when records merge?
Usually the merged record shows the created date of the record that survives. Keep the oldest record as the survivor if the original created date matters.
Should I keep the newest renewal date?
Not automatically. Two different renewal dates may mean two contracts or one mistake. Check those sets by hand.
What if one record has a date and the other is blank?
Keep the date. A blank value shouldn't replace a real one, and in Dedupely blank values never win.
Why did our new-customer report change after a merge?
A merge may have kept a newer "customer since" date. Set that field to keep the earliest value.
Or sign up with Google