# 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.

- **Status:** Available
- **Audience:** both
- **In the app:** #/relationships, #/pipeline, #/follow-ups
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/relationships/merge-safety/

## 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/](/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.

> **Careful** The block case is the one worth checking by hand. A directive that stops outbound on a channel is read from the tag list, and a merged relationship is a good moment to confirm the tag is where you expect it before Connect answers on that channel again.

## Verifying a merge went as expected

1. 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.
2. 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.
3. 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.
4. 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](/docs/relationships/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.

## Related

- [Merging two records](https://connectbyjbrh.com/docs/relationships/merging/)
- [Duplicate detection](https://connectbyjbrh.com/docs/relationships/duplicates/)
- [Lifecycle stages](https://connectbyjbrh.com/docs/relationships/lifecycle-stages/)
- [What Connect remembers about a person](https://connectbyjbrh.com/docs/relationships/person-memory/)
- [Onboarding a new customer](https://connectbyjbrh.com/docs/support/onboarding/)
- [Duplicate follow-ups](https://connectbyjbrh.com/docs/follow-ups/duplicates/)
- [Opportunities: the deal record](https://connectbyjbrh.com/docs/sales/opportunities/)

## What this page is based on

- `docs-source/sources/CHANNELS.md` §5 — what `merge_people` preserves
- `docs-source/sources/CHANNELS.md` §7 — the follow-up duplicate rule
- `docs-source/sources/GENERAL.md` §3 and §6 — canonical records, memory tiers and block tags
- Connect capability registry (docs-source/facts.py)