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.
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 as0551112233is 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.
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.
What a merge does to identities and to consent
Merging two contacts is covered in 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 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.
- 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
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.