Loading
Duplicate detection finds contacts and companies that already exist before a second copy is created. Treepie Flow checks every new record from forms, email sync, the API and imports against existing ones using email, phone, domain, registration number and name similarity. Each match shows its reasons and a confidence score; high-confidence matches can merge automatically, and close calls wait for a person. A merge keeps the history of both records.
Because a duplicate does not just clutter a list. It splits a relationship in half, so the renewal team sees one history, support sees the other, and neither knows the account is at risk.
Duplicate detection matches new contacts and companies against existing ones as they are created or imported, and merging combines them into one record without losing either one's history.
Matching runs on entry, on import and on demand, using rules you can tune. A merge asks which value wins per conflicting field, then moves every deal, ticket, invoice and note onto the surviving record.
Two Harlow Logistics rows, created eight months apart, held four tickets and one open deal respectively. Merged, the deal was suddenly a renewal with an unresolved escalation attached — which changed how it was handled.
It will not merge automatically on a partial match. Two similar companies at one address are sometimes one customer and sometimes two, and that judgement stays with a person.
Import and bulk edit runs the same checks before committing, web forms match against existing contacts instead of creating new ones, and Books avoids issuing a second customer number.
| Manual clean-ups | Basic dedupe tools | Treepie Flow | |
|---|---|---|---|
| When duplicates are caught | Months later | On import only | On entry, sync, API and import |
| Why it matched | Someone’s judgement | Rarely shown | Reasons and a confidence score |
| What survives a merge | Whatever was copied across | One record’s history | Both histories and every field version |
| Close calls | Guessed | Merged or missed | Held for a person below your threshold |
| Undo | Not possible | Rarely | Within 30 days |
The merge is recorded in full in the audit trail. Reversing it is a support operation, not a button, because it is rarely what is actually wanted.
Yes, before the import commits, as part of the diff you approve.
Yes — which fields count and how closely they must match, per object.
Exact matches on email, domain or registration number are near-certain. Name similarity alone scores lower, which is why those matches wait for review by default.
Yes. Choose which keys count, how much each is worth, and the confidence above which merges happen automatically.
Yes. A scan runs across your whole database and queues the matches it finds.
You choose per field, or let the rule keep the most recently updated value. Losing values stay in the field history.
They move to the surviving record, so nothing is orphaned and reports stay correct.
Choosing “Keep both” marks the pair as distinct, and it won’t be suggested again.
Yes. Review a list of matches and merge them together, each merge logged individually.
No. Matching runs as the record is written, before routing picks it up.
Fourteen days, every module, no card. Or half an hour with someone who will run it on your own records and tell you where it does not help.