Why do client cards get mixed up?
A client card is meant to be one person with all their channels. Sometimes, though, something foreign gets in: two different Telegram accounts under one record, a contact that actually belongs to the card next door, or dialogs still attached to a former owner. An operator opens such a card and sees two histories mixed together. This page explains where the mixture comes from, which three situations the platform distinguishes, and why each one calls for a different action.
Context and problem
The platform attaches a new conversation to an existing card by matching phone, email, or username — the same behaviour that gives you useful cross-channel work when one person writes from Telegram, email, and the widget while the card stays single. See Why does one client have many channels? for how that works.
Occasionally the same logic reaches wider than it should:
- a family or a company shares one phone number or one mailbox;
- a person switched to a new messenger account while the old one is still active;
- data was imported from a previous system and some cards arrived without a bot link;
- an operator merged two cards manually and got the match wrong.
The consequences do not show up immediately — they show up in the work: an operator answers based on someone else's history, reports count two people as one, and a broadcast reaches a contact that does not belong to that person.
The three situations the platform distinguishes
The platform scans the database regularly and produces cases — specific places where something got tangled. Every case has a problem class, and the class is what tells you what to do with it.
Multiple accounts on a card
One card has collected contacts that almost certainly belong to different people — for example, two different Telegram accounts within the same bot. Both people's history has merged into a single feed.
There is one card here and two or more people in it. The fix is to pull the extra one out.
Foreign contact
A contact sits on a card it does not belong to: its messages actually concern another card that already exists. The home for this contact is there — it is simply living at the wrong address.
This is the subtlest of the three, because it has two readings. If it is the same person, the cards should be brought together. If the people are different, they must not be — only the contact itself should move.
Stray dialogs
The contacts are already in the right place, but some dialogs stayed attached to a card that is no longer their owner. Such a tail usually trails from an earlier merge or transfer.
Here the contacts need not be touched at all — only the conversations move.
Why there are separate actions instead of one universal fix
A single "repair" button is tempting. We deliberately avoid it: the three situations differ not in size but in direction — in the first, data leaves the card; in the second, it moves between cards; in the third, only conversations move. One action for every case would mean doing too much in some of them.
So a case only offers what makes sense for its class:
| Problem class | What is offered | Why this one |
|---|---|---|
| Multiple accounts on a card | Split off contact(s) | The second person has to leave the card — into a new card or another existing one. |
| Foreign contact | Move contact to owner (recommended) or Merge cards | The first when the people differ. The second when it really is one person. |
| Stray dialogs | Move dialogs to owner | Contacts are already correct; only the conversations move. |
For the Foreign contact class the platform marks the transfer as Recommended and shows a warning before a merge: a merge pulls in the entire source card — all of its contacts, dialogs, and channels. If the card belongs to a different person, that glues two people together instead of separating them. A transfer touches exactly what you selected.
What the platform guarantees while you untangle
Preview first, changes after. Every operation runs through a wizard with the steps Overview, What moves, Field conflicts (merging only), and Result, and a separate Confirm the operation window opens before it runs. Nothing changes in the database until that confirmation — and that fact sits right next to the button: "Nothing changes yet — preview first".
The operation is irreversible. The confirmation dialog says so plainly: "The operation is irreversible." There is no one-click undo — which is exactly why you are shown precise numbers beforehand rather than an estimate.
Everything is recorded. Every completed operation lands in the Operations journal with the actor, the time, and a snapshot of the state before it. On top of that, a service note appears in the feed of every affected dialog — operators can see that the conversation changed cards and do not read it as a glitch.
Historical statistics stay put. Closed dialogs are not re-attributed in reports: they stay with the card they belonged to at the moment of closing. This is deliberate — otherwise every untangling would rewrite reports that have already been delivered.
There is a ceiling on size. Very large operations are refused rather than executed, with the message "The operation exceeds the allowed limit". It protects you from one careless action reshuffling thousands of rows. Such a case is handled in portions, or with help from your administrator.
Cards of different bots are never merged. The attempt stops with "Merging cards of different bots is forbidden": a card shared across two bots would break both access rights and reporting.
Self-healing cases
Some of the cases found need no intervention: they resolve themselves the next time the person writes and the platform re-attaches the contact. These are marked Self-healing and are hidden from the list by default — the tile shows their count with the label "hidden".
That is on purpose: the list should show work, not every deviation at once. The rest of the cases sit on the neighbouring painful tile, labelled "need action" — those are the ones you work with.
What this means for your team
Untangling is not a daily routine. Cases accumulate slowly. A sensible rhythm is to review the list after a scan once a week, or whenever operators report foreign history in a card.
Start from the class, not the number. The problem class tells you at once how painful a case is: "Multiple accounts on a card" disrupts an operator right now, while "Stray dialogs" mostly affects statistics.
Do not rush a merge. If you are not certain it is the same person, open the conversation with Read the conversation right inside the wizard. Two minutes of reading is cheaper than irreversibly gluing two people together.
Access is root-only for now. Only the root user can see the untangling section: the operations rewrite cards irreversibly, so while the feature is rolling out the access is deliberately not grantable to any other role — there is no matching checkbox in role settings. If you cannot find it, contact the instance owner.