Merging Duplicate Customer Records: What Should Your Business App Preserve?

When two customer records describe the same person or business, merging should be a deliberate reconciliation, not a quick deletion. Before commissioning the feature, decide which record survives, how conflicting details are resolved, where linked work goes and what recovery is actually possible. A matching name is a reason to investigate, not permission to merge.

This guide concerns two records already inside a business application. It is not about repeated automation events, importing a database or deciding when to archive an inactive customer.

First establish whether there is really one customer

A shared telephone number might belong to a household or reception desk. Two branches might share a trading name but need separate billing. Conversely, a customer who changed email addresses might genuinely have two records. These are hypothetical situations, not evidence that a particular matching rule is reliable.

For a first version, ask the app to suggest possible matches and let an authorised person decide. Show enough context to distinguish the records: contact details, relevant business identifiers where your system legitimately holds them, and recent linked jobs. Do not expose additional personal information merely to make a comparison screen look complete.

Agree an explicit alternative to merging. Staff should be able to mark a pair as different customers, with a way to reconsider later. Otherwise the same unhelpful suggestion can keep returning.

Choose the surviving record separately from the surviving values

The record identifier and the contents of its fields are different decisions. You might retain the identifier used by an external system while choosing the more recently confirmed phone number from the other record. Neither “keep the oldest” nor “keep the latest” settles every field.

Ask for a side-by-side preview showing:

• The record that will remain and its identifier.
• The proposed name, email, phone number and other relevant values after the merge.
• Every conflicting value that needs a human decision.
• Empty values that would replace existing information, if any.
• Details that cannot be combined and will be discarded or retained separately.

Do not quietly reinterpret communication preferences. Two records with different preferences need an explicit rule appropriate to the business and its obligations, not a blanket instruction to keep whichever value is convenient. Obtain qualified advice where the legal basis is unclear; this article does not establish one.

Count the relationships, not just the fields

A merge can look correct on the customer screen while leaving work attached to the wrong identity. Put jobs, quotes, notes, documents and any other actual relationships into the specification individually. Decide whether each moves to the survivor, remains linked to a historical identity or blocks the merge for review.

Published documents need separate treatment. For example, deciding where an invoice appears in the customer list is not permission to rewrite the customer details printed on an issued invoice. Ask the developer to demonstrate the agreed behaviour without assuming a universal accounting rule.

HubSpot provides a useful product example, not a promise about your app. Its merge documentation says the remaining record combines activities, associations and most property values, and warns that behaviour differs by object type. The word “most” is important. A proposal that merely says “merge customer data” leaves the exceptions unresolved.

Do not assume there is an undo button

The same HubSpot documentation explicitly says records cannot be unmerged. That is a limitation of the documented product, not a technical rule for every system. It shows why recovery must be discussed before acceptance rather than inferred from a familiar-looking button.

For a custom app, ask which recovery arrangement is offered: no reversal, a documented manual repair or a tested reversal feature. If reversal is offered, include work created after the merge in the discussion. Splitting the original two records does not by itself tell the app which customer should receive a new job created afterwards.

A backup is not automatically a practical single-customer undo. Ask what would need restoring and whether unrelated changes made since the backup would be affected. Do not describe the merge as reversible until the agreed method has been demonstrated.

Keep external systems and access out of the guesswork

If another system refers to the retired identifier, ask what happens to that reference. A link that still opens an old record, a later import or a delayed integration update should have a defined outcome. Choose whether the app resolves an old identifier to the survivor, rejects it with a useful explanation or sends it to a reconciliation queue. These are design options, not standard features promised by this guide.

Customer accounts require an additional boundary. Combining contact records must not silently give one login access to another person's documents. If records have separate logins or conflicting organisations, stop for an explicit identity and access decision. A back-office merge is not evidence that two accounts belong to the same person.

A demonstration worth requesting

Use invented customer records and test accounts. Give the two records different phone numbers, one linked job each and a conflicting preference. Then ask the developer to show this sequence:

1. A person without merge permission cannot perform the operation, including by calling its endpoint directly.
2. The preview identifies the survivor, unresolved conflicts and the affected relationships.
3. Cancelling changes neither record.
4. Confirming produces the agreed field values and preserves each relationship according to the specification.
5. An old reference behaves as agreed, without exposing another customer's information.
6. A second attempt does not silently repeat downstream actions or create another combined record.
7. The app records who merged which identifiers and when, without unnecessarily copying sensitive field contents into the history.
8. The documented recovery method works, or the interface clearly states that reversal is not available.

These are proposed acceptance tests, not results of testing a particular product. Record them in your web-app acceptance criteria. If the first release does not need merging, agree how staff should flag suspected duplicates without deleting useful history. A manual review process is preferable to an automatic merge whose consequences nobody can explain.

Questions to settle before approving the feature

Can matching email addresses trigger an automatic merge?

Do not make that the default simply because it is easy to implement. Decide what evidence establishes identity in your actual workflow and which exceptions need review. The recommendation here is human confirmation for the first version, not a claim that automatic matching is always wrong.

Is deleting the duplicate enough?

Only if you have deliberately resolved the fields, relationships, references and access consequences first. Deletion by itself does not specify any of those outcomes.

Should every small app include this?

No. If duplicates are rare, a documented correction process may be enough. Commission a merge feature when the recurring work and risk justify it, and discuss that scope through website and business-app development.

Source and scope

HubSpot, “Merge records”, reviewed for this guide: https://knowledge.hubspot.com/records/merge-records. The cited product facts concern combined data, object-specific behaviour and the absence of unmerge. The proposed preview, identity safeguards, recovery questions and tests are practical commissioning guidance, not claims that HubSpot or any other product implements them.