# Continuing on a different channel

History carries over when the new channel's address resolves to the same Person, because everything durable is stored against the person rather than against a conversation. What does not carry is the conversation itself: a call is not a thread, and the new exchange starts as its own record on a shared timeline. Identity resolution is the hinge the whole handover turns on.

- **Status:** Available
- **Audience:** both
- **Channels:** email, whatsapp, sms, phone
- **In the app:** #/relationships, #/inbox, #/timeline, #/follow-ups
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/workflows/cross-channel-handover/

## The chain

1. Trigger — a customer who emailed rings instead, or somebody who texted asks to be answered on WhatsApp, or a call ends with a promise to put something in writing.
2. External event — the new channel's inbound path fires, or an outbound action is prepared on a channel different from the one the exchange began on.
3. Authentication and workspace resolution — unchanged, and worth stating: the workspace is resolved from the receiving identity on the new channel, not inherited from the old conversation.
4. Ingest — normalised into the same canonical shape every channel produces. This is what makes a handover possible at all rather than a special case per pair of channels.
5. Canonical record — a new conversation on the new channel. Connect does not graft a call onto an email thread; two media with different rules stay two records.
6. Identity resolution — the hinge. The address or number is matched to an identity; a hit attaches the new record to the existing Person, a miss creates a contact and the handover silently does not happen.
7. Knowledge, memory and rules — these carry, because they are held against the person and the workspace rather than against a conversation. A directive set during the email exchange governs the call.
8. Autonomy and approval — resolved for the new channel, not the old one. A workspace that is `autonomous` on email and `ask_before_send` on WhatsApp gets the WhatsApp rule for the WhatsApp leg.
9. Action through a provider — the new channel's provider, with its own constraints: session windows on WhatsApp, carrier capability on phone, and on SMS no outbound at all.
10. Result — recorded with that provider's evidence, on the new record.
11. Relationship, timeline and memory — both exchanges appear in order on one Person, which is where a colleague reads the story as continuous even though the records are separate.
12. Audit and usage — each leg is audited and metered under its own channel, so a handover is visible as two actions with one reason rather than as one action that changed shape.
13. Next — a follow-up booked on whichever channel suits the promise, which may be a third one.

## What carries and what does not

| Thing | Carries? | Why |
|---|---|---|
| Who the person is | Yes, if the identity resolves | Identities hang off one Person record |
| Memory and directives | Yes | Held at workspace, channel, endpoint and contact tiers — not on a conversation |
| Suppression and do-not-contact | Yes | Enforced at the send boundary against the contact |
| Knowledge and standing instructions | Yes | They belong to the workspace |
| Lifecycle stage, opportunities, cases | Yes | All attached to the person or the company |
| The conversation and its messages | No | A new record on the new channel; both show on the timeline |
| Autonomy mode | No | Resolved per channel, narrowest scope first |
| Provider constraints | No | Each provider's rules apply only to its own channel |

## When the identity does not resolve

This is the failure that makes a handover look like amnesia. Somebody emails from a work address, then rings from a mobile nobody has recorded. The call is a call from a stranger: no history, no context, no memory, because none of it is reachable from an identity that does not exist yet. Connect will not guess its way to the right person from a partial match, and a wrong match would be considerably worse than a thin one.

1. Add the new address or number to the existing Person as soon as you notice.
   - Result: The next contact on that channel resolves immediately, and future handovers work without anybody thinking about them.
2. If a duplicate contact was already created, merge rather than delete.
   - Result: Both histories and both identities survive on one record.
3. For customers you already know, record their likely channels in advance.
   - Result: The first message on a new channel is recognised rather than reconstructed after the fact.

> **Note** This is also why a directive set on one channel should usually be widened to the contact rather than left channel-scoped. A block that resolves only for `sms` does nothing when the same person is reached by email, and a handover is exactly the moment that gap shows.

## Questions

### Can Connect start a handover itself?

It books work on the channel that suits the promise, which in practice is what a handover is — a follow-up created from a call and carried out by email, for instance. What it does not do is move an in-flight conversation to another medium on its own initiative.

### Does the customer notice?

They should notice continuity rather than mechanics: their history is present, the answer refers to what they already said, and nobody asks them to repeat themselves. What they should not receive is the same answer twice on two channels, which is a duplicate-work problem rather than a handover one.

### What if the two channels have different autonomy modes?

Each leg follows its own channel's rule, resolved at the narrowest applicable scope. That is deliberate: the risk of an unreviewed reply is not the same on a live call as it is in an email, and one setting for both would have to be wrong for one of them.

## Related

- [One person across phone, email and WhatsApp](https://connectbyjbrh.com/docs/relationships/cross-channel-identity/)
- [Continuing one conversation on another channel](https://connectbyjbrh.com/docs/workflows/cross-channel-continuity/)
- [The customer timeline](https://connectbyjbrh.com/docs/relationships/timeline/)
- [A do-not-contact reaching every channel](https://connectbyjbrh.com/docs/workflows/dnc-across-channels/)
- [Why the machine proposes a merge and a person disposes](https://connectbyjbrh.com/research/one-person-many-channels/)
- [Configuring a channel, end to end](https://connectbyjbrh.com/docs/workflows/channel-configuration/)

## What this page is based on

- `docs-source/sources/GENERAL.md` §3, §5 and §6 — canonical records, autonomy scopes, memory tiers
- `docs-source/sources/CHANNELS.md` §2 and §3 — WhatsApp and SMS behaviour
- Connect capability registry (docs-source/facts.py) — `cross_channel_identity`, `memory_tiers`