What a merge preserves
A merge preserves seven kinds of record from each side: identities, lifecycle stages, follow-ups, deals, demos, cases and onboarding. That list is the guarantee — nothing material is dropped to make the surviving record tidier, and where each side holds something, the two are carried rather than one being chosen for you.
The seven, one by one#
Every row below is carried from each of the two records, never from one of them. The column beside it is the interesting case: what you get when each side holds something of that kind.
| Record | If each side has one |
|---|---|
| Identities | All of them attach to the survivor; each address still resolves to one person |
| Lifecycle stage | Neither stage is silently overwritten; where the relationship stands is then a move_stage you make deliberately |
| Follow-ups | Each is carried; two with the same due time for the same person are duplicates by the follow-up rule |
| Deals | Every opportunity stays on the pipeline with its own value and stage |
| Demos | Requested, scheduled and completed demos all carry |
| Cases | Open cases stay open; resolved ones stay resolved |
| Onboarding | Post-sale steps carry over, so a handover in progress is not restarted |
The reason this list is written down rather than assumed is that a merge is the one relationship operation with no clean undo. A guarantee you can read before you act is worth more than a discovery afterwards.
Why preservation rather than resolution#
A merge could try to resolve conflicts — pick the later stage, keep the newer follow-up, drop the duplicate case. Every one of those choices is a business decision dressed as a data decision, and the product would be making it without knowing why the two records existed.
So the operation keeps both and leaves the judgement where it belongs. The practical consequence is that a merged record sometimes needs five minutes of tidying: one stage move, perhaps a follow-up cancelled. That is visible work on a screen, which is exactly the property a silent resolution would not have.
What is not on the list#
- Memory is held at the contact tier against a contact, and what Connect knows is readable and removable at /docs/relationships/person-memory/ — read the merged record's memory afterwards rather than assuming.
- Blocks live in memory as
block:<channel>tags, not as a field on the person, so check that a block you rely on still applies to the surviving record. - The written summary is regenerated from the records rather than carried; it re-reads the merged set.
- Conversations and calls are not on the list because they were never on the person record — they live in their own tables and reach the survivor through its identities.
Verifying a merge went as expected#
Open the surviving record and count identities.
Result Every address from the two originals should be there. A missing one means the next message from it will arrive as a first contact.
Open the pipeline and the follow-up queue filtered to that person.
Result Deals, demos and dated commitments from each side appear. Two follow-ups at the same time for the same person is the duplicate the follow-up rule describes.
Open the cases list and the onboarding steps.
Result Open work is still open. Onboarding in progress continues from where it was rather than restarting.
Read the regenerated relationship summary.
Result It should describe one relationship. If it reads as two people, the merge was probably wrong and the repair is manual.
Questions#
Are conversations lost when records are merged?
No. Threads, messages and calls live in their own canonical tables and reach a person through identities. Since every identity from each side attaches to the survivor, the two histories are readable on one timeline afterwards.
What happens to two different lifecycle stages?
Neither is discarded in favour of the other. Deciding where the relationship actually stands is a move_stage away, and doing it deliberately is better than inheriting a guess — see lifecycle stages.
Does an in-progress onboarding restart?
No. Onboarding is one of the seven kinds carried across, so the steps already completed stay completed. That is the difference between a merge and re-creating a customer from scratch.