> ## Documentation Index > Fetch the complete documentation index at: https://docs.tied.com/llms.txt > Use this file to discover all available pages before exploring further. # Contacts overview > How contacts are created, identified and merged. A contact isn't a row you fill in. It's Tied's answer to "have we talked to this person before" — and that answer is computed automatically, most of the time, from whatever the incoming message actually tells you. ## The three keys A contact can carry three identifying fields, each unique per account: Your own external ID for this person, if you have one — the field built for systems that already know who someone is before Tied does. Matched case-insensitively. One email can't belong to two contacts in the same account. Stored as `+`, country code, number — no spaces or formatting. ## How cross-channel identity actually resolves When a message arrives on any channel, Tied checks for an existing contact in this exact order: **identifier, then email, then phone number.** The first match wins, and the new touchpoint attaches to that contact instead of creating a new one. The three identifying fields Tied checks in order — identifier, email, then phone number — and what happens when none of them match. The three identifying fields Tied checks in order — identifier, email, then phone number — and what happens when none of them match. **This is why the same person texting you and later emailing you can resolve to one contact.** If both messages carried their email address, the second one matches the first contact instead of creating a duplicate — no manual work required. It's worth being precise about the limit here, too: the match only works on a field the two touchpoints actually share. A contact created from an SMS conversation has a phone number and probably no email. If that same person later emails you from an address Tied has never seen, and the email never mentions the phone number, nothing links them automatically — you get two contacts until something (an agent, a form, an integration) puts the missing field on one of them. Identity resolution is real, but it isn't clairvoyant. ## One contact, many inboxes Every channel touchpoint a contact has is its own record — a contact paired with an inbox, carrying whatever identifier that channel uses (a phone number for SMS, an email address for the email channel, a generated ID for web chat or the API). A contact with a long history might be linked to five of these, one per channel they've ever used, all pointing back to the same identity. ## visitor → lead → customer Every contact starts as a `visitor`. The moment it gains an email, a phone number, or an identity from a social channel, Tied promotes it to `lead` automatically — and it never demotes itself back. Reaching `customer` isn't automated the same way; that transition reflects a business decision you make, not a rule Tied infers on its own. ## When two contacts are actually one person Automatic resolution doesn't catch every case — see the limit above. When you spot two contacts that should be one, merging is a deliberate, explicit action: pick a base contact and a contact to merge into it. Every conversation, message, note and channel link on the losing side moves to the base contact. Where both sides have a value for the same field, the base contact's value wins. **Merging is not reversible.** The contact you merge away is deleted once the merge completes — its history lives on under the base contact, but the record itself is gone. ## Next Standard fields versus what you define yourself. Saved, filtered views over your contacts. Bringing contacts in from a CSV, and how dedup works there. Where a contact's conversations actually show up. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.