A customer writes on Sunday from the shop's WhatsApp number and on Monday from their own. Same person, two
records. **Linked identities** is how you say so without throwing either record away.

## Is it switched on for you

**Linked identities is a paid capability and it is off unless your plan includes it.** It is not a switch in
account settings, and an administrator cannot turn it on from the dashboard.

How to tell, in ten seconds: open any contact and look at the tabs. If there is an **Identities** tab, you have
it. If there is not, the account does not include the capability — there is no permission you could be granted
and no setting to find. Ask whoever owns your Lynomia Chat subscription.

The rest of this article assumes the tab is there.

## Primary and linked are different jobs

| | What it is | What it is for |
|---|---|---|
| **Primary** | the contact's own phone number and email address — one of each, unique in the account | what an outgoing conversation uses |
| **Linked** | any number of extra numbers and addresses, on the Identities tab | matched when a message **arrives** |

The tab shows both, under **Primary** and **Also reachable at**, and keeps them apart on purpose.

**Linking a second number does not give you a choice of which number to message.** It means a message *from*
that number lands on this contact instead of creating a new one. Primary fields are set on the contact itself —
see [contacts](contacts).

## What a link actually does

When a message arrives, Lynomia Chat looks for its contact in the order it always has: the identifier, then the
email address, then the phone number and its provider variants. **Only when all of that finds nothing** does it
check linked identities. If a linked value matches, the message is delivered to the contact that holds it, and
no new contact is created.

The match is exact. Nothing compares names, avatars or usernames, nothing is judged by similarity, and nothing
is ever merged automatically.

## Linking one

**Identities** tab → **Link another number or address** → choose **Phone** or **Email**, type the value, then
**Link**.

- **A phone number is stored in international form** — `+96550001234`. A local number such as `0551112233` is
  only accepted if the contact already carries a country; otherwise it is refused. This is the same rule the
  contact's own phone field follows, and Lynomia Chat will not guess the country.
- **An email address is stored in lower case.** Case does not matter when you type it, or when a message
  arrives carrying it.
- Each row says where it came from: **Linked by an agent**, or **From a merge**.
- **Unlink removes the row at once, with no confirmation step.** After that, the next message from that value
  creates a new contact again.

## The conflict refusal

A value belongs to exactly one contact in your account, counting primary fields and linked rows together. Try to
link one that is taken and the tab refuses it:

*This already belongs to another contact in this account (contact 4182).*

Three things to know about that refusal:

- **Nothing was stored.** The link was not made and neither record was changed.
- **It names the other contact by its id number, not by name.** The number is that contact's own id; find the
  record and you find out who already holds the value.
- **Nothing is merged.** Lynomia Chat will not decide on your behalf that two records are one person. If they
  are, merge them — which is in [contacts](contacts).

## Who can do what

| Action | Who |
|---|---|
| See the Identities tab and read the list | anyone who can open the contact |
| Link a number or address | administrator, or a custom role with **Manage contacts** |
| Unlink one | administrator, or a custom role with **Manage contacts** |

Reading follows the contact, like its notes and its history. Writing follows **merging**, and for the same
reason: both decide where this customer's next message is delivered. See
[roles and permissions](roles-and-permissions).

## What a merge does to identities and to consent

Merging two contacts is covered in [contacts](contacts). Two parts of it belong here, because they are the parts
that are easy to get wrong.

**The number and address you would otherwise have lost become linked identities.** A contact holds one phone
number and one email address, so a merge keeps the surviving record's values and the other record's go with it.
Immediately after the merge they are recorded on the survivor instead, marked **From a merge** — so the next
message from that number reaches the right person rather than recreating the duplicate you just removed. On an
account without linked identities the merge still works, and those values are simply gone.

**Consent keeps the strongest refusal.** Both records may hold a decision about the same thing, and the question
is not which row to keep but what the two together mean. The order is fixed:

**suppressed** beats **withdrawn** beats **granted**

| One record says | The other says | The survivor ends up |
|---|---|---|
| granted | granted | granted |
| granted | withdrawn | **withdrawn** |
| granted | suppressed | **suppressed** |
| withdrawn | suppressed | **suppressed** |

Never the other way round. **A merge can never re-permit marketing to somebody who opted out.** That matters
because a merge is administrative tidying-up, not a moment when anybody asked the customer anything.

When the stronger decision is the one on the record being removed, its evidence travels with it — the source,
the timestamp and the note — so the refusal can still be accounted for months later. [Messaging
consent](messaging-consent) explains the states themselves.

## Limits

- **Phone numbers and email addresses only.** The identifier is not an identity type. It stays the contact's own
  single field, set by an import or the API.
- **One contact per value, per account.** Checked across primary fields and linked rows at the same time, which
  is why you cannot link a value that is somebody's primary number.
- **A linked identity cannot be promoted to primary from this tab.** There is no such control. Edit the contact,
  or merge.
- **Turning the capability off hides the tab but unlinks nothing.** The tab disappears and nobody can link or
  unlink — but a message carrying a value that was already linked still reaches the contact that holds it. That
  is deliberate: silently sending a customer's replies somewhere else is worse than either state.
- **Linking is not written to the account's audit log.** A merge is, with counts and ids only. A link is not, and
  the tab says only that an agent linked it, not which agent. See [audit logs](audit-logs).
- **It does nothing for reach.** Linking is not consent, not a subscription, and not a second channel. It only
  affects where an arriving message is delivered.

## Related

- [Contacts](contacts)
- [Messaging consent](messaging-consent)
- [The customer's full picture](customer-360)
- [Import contacts](import-contacts)
- [Roles and permissions](roles-and-permissions)

## If it does not work

**There is no Identities tab on any contact.** The account does not include linked identities. It is a plan
capability, not a permission, so no administrator can grant it to you.

**The tab is there but there is no Link button and no Unlink.** You are an agent without **Manage contacts**.
Reading the list is open to everyone who can open the contact; changing it is not.

**"...is not a phone number or an email address we can use."** Either a local phone number on a contact with no
country set, or something that is not a valid email address. Write the number in full international form, or set
the contact's country first and try again.

**I linked a number and the next message still created a new contact.** Compare the value on the tab with the
number the message actually arrived from, digit for digit — the match is exact. Also check that the message did
not already resolve some other way: the linked-identity check only runs when the ordinary identifier, email and
phone lookups all come back empty.

**A merge removed a contact and its campaign history disappeared from my reports.** It did not. Campaign
recipients, support cases, cart attribution and labels all move to the surviving contact. Where both records had
a row for the same campaign or the same store, the survivor's is kept and the duplicate is discarded — and the
count of what was discarded is in the audit entry for that merge.