Review duplicate customer records before an import

Write the identity rule before searching. A contact is a person, while a company is an organization, so a shared company name does not make two contacts the same person. A company can also have more than one trading name or domain. Keep those distinctions visible in the review rather than forcing every row into one customer label.

For each record type, list the strongest identifiers already available. A source-system record ID is useful when both files refer to the same system. For contacts, an exact email match is a strong clue. For companies, a matching domain can help. Names, phone numbers, and postal addresses add context, but may be shared, outdated, or formatted differently.

Start with exact identifiers, then compare secondary details. Normalize harmless formatting such as letter case or spaces in a phone number, but keep the original value in the review file. Do not silently discard a difference because it may explain why the records diverged. A person who changed jobs, for example, may still have a different current organization.

HubSpot documents contact deduplication using email and company deduplication using domain values in specified workflows. It also describes record IDs and custom unique properties for matching records during imports. Those are HubSpot rules, not a universal identity standard, and its documentation notes an exception for companies created through an API. Treat every destination system's behavior as something to confirm.

Give each pair a stable label such as A-014 and B-009. Record the shared signal, the conflicting detail, a decision, and the reason. The example CSV includes both likely matches and lookalikes. One pair shares a fictional company domain, while another shares a familiar name but has different domains. That second pair should remain separate unless stronger evidence appears.

Use three outcomes: merge after review, keep separate, or investigate. The queue should make uncertainty explicit. A blank decision is not permission to merge, and a fuzzy name match should not be converted into a confirmed identity just to make the import file look tidy.

When a pair is a genuine match, decide which value should survive for each important field. Use a source that has an owner and a reason for being trusted, such as a current client-confirmed address or a system-generated record ID. Do not assume that the newest timestamp is correct, because imports and edits can change timestamps without improving the underlying information.

Preserve useful history and links where the system supports them. If a merge would erase a note, relationship, or source reference that the team needs, pause and capture that information first. For uncertain pairs, keep separate records and add a review note rather than guessing.

Filter the queue to records with a recorded decision. Keep confirmed matches in a reviewed file, new customers in a separate file, and unresolved candidates out of the import. Compare the final row count with the original input so that removing duplicates does not accidentally remove a real person or company.

After import, check a few reviewed pairs in the destination and confirm that the intended record was updated or created. This page focuses on identity review. A separate small-sample migration test is useful when you also need to check field mappings, associations, and how the destination handles a broader data move.

Give Areinum Assistant a permitted sample of candidate records and ask for a review queue showing matching identifiers and conflicts. A person decides whether each pair represents the same customer and what should be retained.