Duplicate records are rarely just a search inconvenience. They can divide customer history, create repeated communications and confuse integrations that expect a stable identifier. Yet two similar names are not always the same customer. A useful duplicate strategy combines prevention, review and a careful merge process. Begin with the business identity you are trying to represent: a person, a trading entity, a location or an account relationship.
Define what makes two records the same
Imagine a Warrnambool supplier serving a customer with two depots. Staff create separate records because each depot has a different delivery address, while accounts expects one billing relationship. The right solution may be one customer with two locations rather than deleting one record. Identify stable business identifiers where available and use names, addresses or email as supporting clues rather than automatic proof. Show possible matches during record creation, but give staff enough context to distinguish a genuine new customer from an existing relationship with similar details.
Review field conflicts explicitly
A merge should show which values disagree and allow a responsible person to select the intended outcome. Preserve useful alternative contact details where the data model supports them. Decide how active jobs, notes, documents and external identifiers move to the surviving record. Some identifiers may need to remain as aliases so old links or integrations can still find the correct customer. Record the reason and actor for the merge. If a merge cannot be reversed safely, make its scope particularly clear before it is applied.
Protect the connected history
Combining records often changes several related tables or services. Database transactions, as explained by PostgreSQL, can group related changes inside a database, but an external CRM or accounting platform may require a separate coordinated process. Ask the team to identify where partial failure could occur. A merged local record with two active external customer accounts may still produce duplicate communication. Provide a visible state for unresolved downstream work rather than treating the merge as complete before all intended relationships have been checked.
Trial the hardest ordinary example
Use fictional duplicates with active jobs, conflicting contact details and separate external identifiers. Walk through the merge and confirm that search, history and integrations remain understandable. Document:
- The business identity represented by a customer record.
- The evidence needed before two records may be merged.
- How field conflicts, related work and old identifiers are handled.
- Who can perform merges and how incomplete downstream changes are resolved.