Duplicate management is a control loop. Put records into a comparable view, test whether they are the same, choose the record to keep, and check the result. The merge boundary is where the costly error occurs. A CRM and an email platform may define "contact" differently, so a merge can do something subtly wrong that nobody notices for a month.1 For every candidate, confirm identity, relationships and system behavior before you commit.
Run the cleanup
Use the table in order. Move on after answering the question in the middle column, and leave uncertain matches in review until the identity decision is clear.
| Stage | What you are trying to learn | Example question |
|---|---|---|
| Prepare | whether the list can be compared with the CRM | Can this prospect list be put into a CSV and deduped against the CRM?2 |
| Find | what detection coverage exists | When does the local check run, and how can we run a full database search? |
| Verify | whether matching records describe the same person or account | "How are duplicate people, multiple phone numbers, merged records and deleted records handled?"3 |
| Select survivor | which record should remain | Which record carries the history and relationships worth retaining? |
| Merge | what moves with the selected record | Which related records will move with this record? |
| Check | whether the outcome is recorded and recoverable | Where will I see the merge history, and what happens if the merge was wrong? |
Prepare candidate records
Start with the path that created the records. Manual entry and bulk import can both introduce duplicate records.4
For CSV work involving accounts, use the existing account name in the CSV and check that the accounts in the file match the existing accounts.5, 6 Keep the original list beside the CRM view while you compare matches, so each decision remains traceable to the input.
Find candidates
Run entry checks alongside database sweeps. An entry check catches a record while its context is still available, while a sweep lets you work through the existing database.
A local duplicate search runs automatically when a new record is saved.7 A bulk duplicate search covers the entire database manually or on a schedule.8
When you already know which records need attention, you can merge them manually without running a search.9 This option is available across all sections.10 If duplicate search is absent from a Freedom UI list page, a no-code developer should add a button that triggers the action "Open duplicates page".11 Ask the administrator to add duplicate-detection rules for other situations that the current checks miss.12
Verify identity
Use this pass to decide whether similar records represent the same entity. Compare identity fields with the relationship context, and hold the candidate while the reason for the match remains unclear.
A deliberate duplicate can exist when a contact needs relationships with more than one account as a workaround for the data model.13 That case needs a relationship decision, not an automatic merge. Review each potential duplicate and choose to merge or skip it individually.14
Select the survivor
Once identity is clear, choose the surviving record before starting the merge. Write down the choice and confirm how the CRM treats the record you open.
In a workflow where the current page is retained, the open page stays the master and selected records are combined into it.15 Confirm that behavior before opening the record you intend to preserve. Then check the linked records and field values that must remain available after the merge.
Validate the outcome
Validation is a separate pass. A completed merge needs a record of what happened and a way to investigate an error.
The merge view shows how and when records were merged.16 Use that history to check that the intended records were handled at the intended point in the process.
If a merge is made in error, previously lost progress can be recovered by contacting the Account Manager when applicable or the Customer Support Team.17 Record the decision and the reason for it alongside the merge history so the next review has context.
Prevent new duplicates
Put control upstream in record creation and import. Resolve a likely match before it becomes another cleanup candidate.
When a similar account or contact already exists, a duplicate-detection dialog can appear.18 Use a flow that lets the user create a new record, use the existing record or skip creation.19
For unique fields such as an email address or phone number, a CRM may offer a "Do Not Allow Duplicates" setting.20 Enabling that setting prevents another record with the same email address or phone number from being created.21 Apply the setting only where the field represents a true uniqueness rule for your process.
What not to do
Keep these failure modes out of the workflow:
- Do not merge every apparent match. A duplicate can be deliberate when a contact needs relationships with more than one account.13
- Do not merge before checking related or child records. Merging a record also merges those related or child records.22
- Do not treat cleanup as cosmetic. Duplicate records can affect productivity, increase manual work and show incorrect data in reporting.23
- Do not force a merge when the match is uncertain. Review the candidate and choose merge or skip individually.14