Preview a CRM contact merge without losing the sales history

Plan the contact review your CRM needs

Maya has two contact records. One holds a won project; the other holds an inquiry for a different job. Bringing her contact details together should leave both jobs, their stages and their notes easy to trace.

Use this fictional example to prepare a contact map and a set of checks for your app brief. Overskill's CRM starting page helps you describe the workflow you want to build. Start with a preview that shows every proposed change before adding any ability to change real records.

The exercise uses six invented contacts. It prepares a proposal only. Keep real client information out of the public exercise.

Review the three candidate pairs

The fictional reviewer has already supplied these identity decisions. Similar names, phone numbers or shared email addresses alone do not establish that two records describe one person.

Scroll horizontally to compare all columns.

Your app should record who made an identity decision, when they made it and what evidence they used. When that decision is missing, leave the pair for review. If you are still deciding what your source rows represent, use the spreadsheet mapping guide first.

Choose the contact and field values to keep

For Maya, choose C01 as the contact ID to retain. Preserve C02 as an alias: a recorded link from the old ID to the retained ID. Keep the original records so a reviewer can still see what each contained.

Then make each conflicting field choice explicit. This worked result chooses the full name from C01 and the phone number from C02. Both source records have the same email, so there is no email conflict for this pair.

Scroll horizontally to compare all columns.

Choosing C01 as the retained ID does not settle which phone number is correct. The example's phone choice is an explicit exercise decision. In your own workflow, the reviewer needs evidence for it.

For Sam, retain C05 and select the new email from C06. The phone values also need a decision: C05 has a missing value and C06 has an empty text value. Neither supplies a phone number. For this worked result, choose C05's missing phone value and record C05 as its source. Your own workflow needs an explicit rule for missing and empty values; do not invent a number to complete the proposal.

Trace every job and note

When both eligible pairs are resolved with C01 and C05 retained, the proposed contact map contains four retained contacts and two aliases. The original six-contact snapshot remains intact. There are still five distinct deals and six distinct notes.

Scroll horizontally to compare all columns.

Read the individual rows as well as the totals. D01 and D02 now point to the same contact, but remain separate jobs with different stages. Jordan's and Casey's jobs remain attached to their respective contacts. N06 moves in the proposed map even though C06 has no deal.

Record the aliases C02 → C01 and C06 → C05 separately from the deal and note counts. An alias preserves an old contact reference; it is not another job or another person.

Keep communication evidence separate

Maya's source records contain conflicting email-permission evidence. Sam's old email has a recorded grant, while the new email has no supplied decision. Preserve each source entry with its address, decision and date. This exercise does not calculate a combined permission or send messages.

Choosing a preferred email changes a proposed contact field. Any future communication workflow needs its own review of the evidence and rules for that address.

Review again when inputs change

A proposal belongs to the source snapshot and choices that produced it. Keep the source version, reviewed pair IDs, retained IDs, field sources and before/after links together in the proposal.

If you change a field choice, the old preview should immediately stop being presented as current. It can remain visible as previous reviewed work, clearly labeled, while you complete another review. Missing choices or a failed review must not quietly reuse the previous result.

Recheck the whole source when preparing the final proposal. A changed note, deal stage, identity decision or permission entry can matter even when the contact count stays the same. A changed source requires a fresh review.

Build and test the preview workflow

Use the app brief builder to describe your first version. Keep the first test small enough that you can check every record.

Build a staff-only CRM contact review using fictional sample records. Only authorized staff in the same workspace may see contacts, candidate pairs, deals, notes or proposals.

Start with a preview-only workflow. Require a recorded identity review before a pair can be proposed for consolidation. Keep the household pair separate. Let the reviewer choose the retained contact ID and the source of each conflicting field.

Show original and proposed contact links for every deal and note. Preserve their IDs, stages, text, authors and times. Keep original snapshots and record the old contact IDs as aliases. Preserve communication evidence separately without deciding permission or sending anything.

Bind each proposal to the reviewed source snapshot. Editing a choice must invalidate the current preview immediately. Missing choices and changed sources must require review. Exclude applying or undoing a live merge from this first version.

Test the resulting app with accounts and data you control:

Use the private-record access guide to expand the account checks. A correct public exercise does not establish access control in the app you build. Review the actual saved records and account boundaries before considering a separate live-merge feature.