---
title: "Contacts, channel identities and linked records"
description: "One human can occupy several contact records in CloudFly Helpdesk. How channel identities work, what linking asserts, and why a link is transitive."
updated: "2026-08-28"
audience: [agent, administrator]
source: "https://helpdesk-docs.svr1.feedapp.click/en/khai-niem/contact-va-ho-so-lien-ket"
---

One human usually occupies several records here, one per channel. Folding them
together is a person's work rather than an algorithm's, and this page explains
the model behind that action.

It is also the most delicate corner of the system: one link placed wrongly puts
one customer's history under another customer's name.

## A contact is the record of a person outside the workspace [#a-contact-is-the-record-of-a-person-outside-the-workspace]

A **contact** holds a name, an email, a normalized phone number, free-form
attributes, tags and a blocked flag. Conversations and tickets both point at
it, which is where those two kinds of work record meet.

A contact is created by the first message from a stranger, or by hand. It
carries no notion of a channel: the channel lives in the identity layer beneath
it.

## Channel identities [#channel-identities]

Each channel recognizes a customer by an id of its own. The system stores those
ids as identities, each one a provider plus an external id:

| Channel        | Id that is stored                      | Who asserts it                                      |
| -------------- | -------------------------------------- | --------------------------------------------------- |
| Facebook       | The Page-scoped PSID                   | Meta                                                |
| Zalo           | The Zalo UID                           | Zalo                                                |
| Telegram       | The chat id                            | Telegram                                            |
| Website widget | An id the customer's browser generates | Nobody — it is a value the browser stores and sends |

That last row deserves to be told apart from the three above it. A PSID is
asserted by Meta, while a widget id lives in the customer's browser: clearing
browser data produces a new one, and a change of device produces a new contact.

A provider and external id pair belongs to exactly one contact. An incoming
message never moves an identity to a different contact, because an identity
changing hands means a person's account changing hands.

## Why one human ends up with several records [#why-one-human-ends-up-with-several-records]

Nothing ties a Facebook PSID to a Zalo UID. The system folds two records
together on a matching email or a matching phone number; beyond that, the
evidence has to come from a person stating it.

So a customer who writes from Facebook today and from the widget next week
generally produces two contacts, each carrying its own history.

## A link is a judgement, and it is attributed [#a-link-is-a-judgement-and-it-is-attributed]

In the contact drawer, the **Linked records** block is where you assert that
two records are one person. **Link a record** opens the suggestions under the
heading **Might be the same person**, each with its reason: **same phone**,
**same email** or **same name**.

Those three reasons are not equal. A shared phone number is close to proof, a
shared name is only a reason to look, and the console ranks them in that order.
No suggestion creates a link on its own.

A link is reversible through **Unlink**, whose confirmation reads **Not the
same person?**. Linking and unlinking both leave a line in the contact's
history, naming the person who did it.

## Linking is transitive [#linking-is-transitive]

A link is a group rather than a pair. Link A to B and then B to C, and A sees C
as well, because all three belong to one person — and joining two groups merges
them rather than breaking either apart.

Unlinking takes one record out of the group and leaves the rest in place. A
group left with a single member dissolves, since one record on its own asserts
nothing.

> **Warning:** Linking the wrong pair puts one customer's history under another customer's
> name on the staff screens. Before linking, check a piece of real evidence: a
> phone number, an email, or the customer saying so in the conversation.

## Customers never see this widening [#customers-never-see-this-widening]

Widening history across a linked group belongs to the staff screens. The
**Other conversations** list in the contact drawer spans every linked record,
and prints each record's name and email so you can tell which thread sits on
which profile.

The customer-facing reads stay narrow. A customer's chat panel and the customer
portal remain scoped to one inbox and to that session's own contact, so a bad
link does not push one person's history into another person's chat window.

## Insight — the notes no API can supply [#insight--the-notes-no-api-can-supply]

The **Insight** block in the same drawer holds what a colleague typed by hand: a
Zalo group, a CRM record, a second phone number. Each entry carries a label, a
value type and the name of whoever wrote it, so a stale entry has somebody to
ask.

Insight is not the same thing as a link. It records another place the business
reaches this customer, rather than asserting that two records are one person.

## Read next [#read-next]

* [Glossary of helpdesk terms](/en/khai-niem/thuat-ngu)
* [Conversations versus tickets](/en/khai-niem/hoi-thoai-vs-ticket)
* [Working the shared inbox](/en/hop-thu)