A duplicate-record merge should let someone identify the records involved, choose the surviving values, understand what happens to linked information, and inspect the resulting record. A generic “Are you sure?” dialog cannot carry those decisions. The comparison needs to show the proposed result before the person commits.
Imagine a fictional purchasing workspace, Alder, with two records for Northline Paper. Procurement has established that they describe the same supplier, but their phone numbers, address fields, and purchase-order associations differ. Build a Mockitt prototype of the comparison and resulting supplier record to review those choices together. This example defines a proposed merge policy; the production system's data rules must support it.
Make the two supplier identities easy to distinguish
The comparison opens with SUP-104, “Northline Paper,” and SUP-287, “Northline Paper Ltd.” Keep both identifiers beside their names throughout the flow. Similar names are the reason the records were investigated, not sufficient evidence that they should be merged. Show the information a reviewer used to establish identity, such as the shared fictional supplier reference EXT-482, and allow them to return to either full record.
In Alder's proposed policy, SUP-104 is the surviving record. Its identifier remains available and SUP-287 becomes a recorded merged reference. Explain that meaning beside the primary-record choice. “Primary” should not silently imply that every value in that record is more accurate.
This distinction matters after an import: detecting a match, updating an existing row, and merging two saved records are separate operations. Keep file mapping and commit decisions in the CSV import flow, then provide a deliberate route to review any duplicates that remain.
Show a proposed value for each meaningful difference
Do not make the reviewer remember which column wins. Each conflicting field should show both source values, the selected result, and the source of that result. For Northline Paper, the proposed comparison has three decisions:
- Supplier name: SUP-104 says “Northline Paper”; SUP-287 says “Northline Paper Ltd.” The reviewer selects the latter as the resulting name while retaining SUP-104 as the record identifier.
- Phone: SUP-104 has +1 202-555-0142; SUP-287 has +1 202-555-0176. Both are fictional example numbers. The result remains unresolved until the reviewer chooses the intended contact number.
- Address: SUP-104 is empty; SUP-287 contains “14 Wharf Lane.” The comparison suggests the populated value and labels its source, so a filled field is not silently mistaken for independently verified information.
A recent edit can help someone investigate a difference, but it does not prove that the value is correct. Show useful provenance, such as the source record and its field history, rather than automatically presenting “newest” as “best.” If both phone numbers serve different purposes, offer a supported way to preserve labeled contacts or let the reviewer stop and resolve them first.
On a narrow screen, keep the field name, both alternatives, and selected result together. Stacking complete field comparisons is easier to follow than showing all of SUP-104 first and forcing the reviewer to remember it while scrolling through SUP-287.
HubSpot's record-merge documentation provides a useful real-product comparison: people can choose retained property values, and primary values are generally preferred with documented exceptions. It also describes association behavior and states that records cannot be unmerged. Those are HubSpot's rules; they demonstrate why another service must explain its own rules explicitly.
Expand the purchase orders behind the count
SUP-104 is linked to PO-204 and PO-219. SUP-287 is linked to PO-219 and PO-233. Alder's proposed result links three distinct orders: PO-204, PO-219, and PO-233. Show that list, including which association came from each supplier record, instead of presenting “4 orders combined.” PO-219 is the same order referenced twice.
Changing an association does not merge the orders
The intended operation changes which supplier record the orders reference. It does not combine their line items, change approval states, or settle payments. Put those boundaries beside the association preview, where they affect the reviewer's decision. Two orders with similar amounts but different identifiers remain distinct unless a separate, supported process resolves them.
Other relationships may need different rules. A primary contact, restricted attachment, or external-system link might not follow the same “keep every unique association” policy. Surface a conflict at the affected relationship. If the proposed result cannot preserve it safely, block this merge and explain what needs attention.
Make the confirmation specific to this merge
After the reviewer chooses the phone number, show a compact preview: SUP-104 will be named Northline Paper Ltd, use +1 202-555-0176 and 14 Wharf Lane, and link the three listed purchase orders. SUP-287 will no longer be a separate supplier record. Keep Back available so the person can revise these choices without rebuilding the comparison.
For this example, there is no self-service unmerge. Say so beside the final “Merge supplier records” action. Keep any supported administrative recovery process distinct from a guaranteed Undo button. The consequence and recovery guidance for destructive actions is useful here because rebuilding a similar record later is not the same as reversing every relationship change.
Recheck changes made while the comparison was open
Suppose another colleague updates SUP-287's phone number during the review. Before committing, Alder should identify the changed field and ask the reviewer to reconsider that selection. Preserve unaffected choices. Quietly replacing the selected number would change the decision; merging from an old snapshot could discard the colleague's work.
The ability to view suppliers is not automatically permission to merge them. Check authority again at commitment and explain a changed permission without presenting success. Keep the full role-management task in the roles and permissions interface.
Finish on a record the reviewer can verify
Alder's proposed acceptance rule is one completed supplier merge or no changes. Confirm that this is achievable before presenting the operation as all-or-nothing. While it runs, prevent duplicate submissions and identify the records involved. An explicit rejection should preserve the review choices and explain the problem; a lost response should show “Checking merge status” until the service establishes whether the merge happened.
After success, open SUP-104 with the selected name, phone, address, and three orders visible. Include a durable merge-history entry showing SUP-287, the actor, time, and affected information. An old SUP-287 reference should lead to the surviving record with a clear explanation under this policy, rather than strand someone on a generic missing-page screen.
Review the result using a concrete task: find PO-233, identify which phone number survived, and explain what happened to SUP-287. If the reviewer cannot answer, improve the result screen before adding more confirmation steps. When the product later supports several merges at once, design separate selection and partial-failure behavior for bulk actions; one successful pair does not establish a safe batch workflow.