Find duplicate contacts in FileMaker before cleaning your data

1. Decide what counts as a possible duplicate

Two rows can share an email address without being the same person. A team inbox, a family address or an assistant’s address may legitimately appear on several contacts. Conversely, one person can have two different email addresses. Treat duplicate detection as a way to build a review queue, not as proof that a record should be deleted.

For this exercise, use a separate Contacts practice table with ContactID, FullName, Company and Email, all Text fields. Download the fictional five-row review set, or enter it by hand. The exercise ends with review decisions; it does not perform a merge.

2. Read the example before finding anything

The intended outcome is two candidate groups, containing four records. The Ana pair needs investigation; Ben and Lina should remain separate people even though their email matches. C-105 should not appear in the repeated-email result.

3. Find and sort the candidates

1. On a layout based on Contacts, enter Find mode.
2. Enter ! in the Email field and perform the find. FileMaker uses this operator to find duplicate values.
3. Sort the results by Email, then FullName and ContactID, so each candidate group is easy to inspect.
4. Record the candidate IDs before making any changes.

This is an initial screening technique. FileMaker’s indexing and duplicate-matching behavior is not a universal byte-for-byte email comparison. Review the actual values and consult the Claris duplicate-find documentation when exact matching matters.

4. Compare identity and related work

For the Ana pair, check the company, phone, address, source and history. In a real file, also inspect notes, tasks, invoices and other records linked to each ContactID. A contact with little visible detail may still be the parent of important related records.

Write a decision for each group: keep separate, investigate, or prepare a reviewed merge. For our fictional shared inbox, record “Ben and Lina are different people; keep both.” For the Ana pair, record “possible duplicate; confirm identity and related-record ownership before merging.”

Do not decide solely by record age or which name is formatted more neatly. The record you retain should be chosen through a consistent policy that preserves the necessary history.

5. Keep cleanup separate from matching

If a later review needs case or surrounding-space normalization, use a separate review field or an exported working list. Preserve the original email. Do not strip punctuation, remove plus suffixes or apply one provider’s address rules to every address; those transformations can combine distinct mailboxes.

Blank values need their own completeness review. They do not identify a person. Similarly, a repeated surname is a weak matching signal. Combining several clues can improve a review list, but it still needs a decision about what those clues mean for your business.

6. Plan a merge as a separate operation

• Keep a verified backup before a real cleanup.
• Choose a surviving ContactID and document the decision.
• Identify all related records and any external systems that reference the other ID.
• Resolve conflicting field values explicitly.
• Test reassignments and verify related-record counts in a copy.
• Remove or archive a redundant record only after the relationship checks pass.

These are review steps, not an automatic merge recipe. A generic delete-duplicates script cannot know your business rules or every dependency. Finished result: four candidates reviewed, with the shared inbox contacts kept separate and no records deleted.

References

• Duplicate values

Use a practice copy and verify the result in your FileMaker version. Menu wording and platform behavior may differ.