A duplicate finder should produce candidates, not decide that two people are the same. Commission the review and merge workflow separately. The important result is a trustworthy customer record with its history intact, not simply a lower contact count.
Related service: CRM, ERP and web application development- 01Find candidate records.
- 02Compare identity evidence and conflicts.
- 03Preview fields and relationships.
- 04Approve and record the merge.
- 05Verify history and downstream references.
SECTION 01
Keep matching confidence separate from approval
Names, phone numbers and email addresses are useful signals, but each can be shared or change. Ask the agency to show exact matches separately from possible matches. A common office number should not join every employee into one person. Keep a reason for each candidate so a reviewer understands why it appeared.
Decide which fields survive when two confirmed duplicates disagree. Recent does not always mean correct: a recent import can contain older information. Preserve external system identifiers rather than overwriting them with the surviving CRM identifier. PostgreSQL's constraint documentation is a useful reference for identifiers and relationships, not a substitute for deciding business identity.
SECTION 02
Illustrative example: two records for a returning buyer
Suppose a buyer submits a new inquiry using a different work email. One record has open opportunities and the other has support notes. A reviewer confirms they are the same person, chooses the current contact details and previews which opportunities, tasks and notes will move. This is an illustrative workflow, not a client result.
The buyer also represents another organization. Keep that relationship distinct instead of assigning every activity to the newest employer. Check whether moving a private note would expose it to a wider team. A merge is both a data operation and a potential permission change; the review screen should make that consequence visible.
SECTION 03
Start with reviewed merges and an exception report
A practical first release supports one record type and manual approval. Prefer an existing CRM's supported merge facility if it preserves the relationships you need. Custom work is more defensible when cross-system identifiers or unusual relationships cannot be handled safely by configuration.
Test conflicting owners, a record updated during review, repeated confirmation and a downstream integration that still references the retired identifier. Request a before-and-after record of the operation and a documented recovery approach. Some systems cannot reliably undo a merge; say that before approval rather than presenting a misleading Undo button.
SECTION 04
Frequently asked questions
Should identical email addresses merge automatically?
Not without rules for shared addresses, account relationships and conflicting data. Use the match as evidence and choose an approval policy appropriate to the records.
Can duplicate merging change access?
Yes. Moving notes or opportunities under a different owner or organization may change who can see them. Include those effects in the preview.
What should we ask the agency to demonstrate?
A reviewed merge with conflicting fields, preserved activity, continued external references and the agreed recovery procedure using safe sample data.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Database constraintsPostgreSQL
- Authorization guidanceOWASP Foundation
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy