> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dmly.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Contacts overview
> What a contact is in DMLY: one person, owned by your workspace, across every channel they message you on.
A contact is one person. Not a WhatsApp number, not an Instagram handle — the person behind
them. Contacts belong to your Workspace, not to a channel, so the same profile carries their
messages, tags, notes, pipeline stage and billing history no matter where they reached you.
Open **Contacts** from the main menu. DMLY describes the list as "People who interacted
through your connected channels", and that is exactly what it is: everyone who has messaged
any connected channel, plus anyone you added by hand or imported.
## The thing that surprises people first
**The same person messaging you on two channels arrives as two contacts.**
DMLY does not link contacts across channels automatically. An inbound message is matched
against the identities on the channel it came in on, and nothing else — so the customer who
WhatsApps you and later texts your SMS number lands as two contacts, and an Instagram DM
from your best WhatsApp customer lands as a third. Same phone number or not, it makes no
difference here.
This is not something you can change from the app. The fix is to merge them — see
[When one person becomes two contacts](#when-one-person-becomes-two-contacts) below.
## One contact, many identities
Every channel a person reaches you on adds an **identity** to their contact — one row saying
"this person, on this channel, is this id". A contact can hold several. The contact page
lists them under **Channels**, with the channel they first arrived on marked **Primary**, and
explains the point in a line: "One profile, many channels — replies, history and CRM data are
shared."
What each channel uses to identify someone:
| Channel | How the person is identified |
| ---------------------- | -------------------------------------------- |
| **WhatsApp** | Their phone number |
| **SMS** | Their phone number |
| **Facebook Messenger** | An id issued by Meta, scoped to your page |
| **Instagram** | An id issued by Meta, scoped to your account |
| **Telegram** | Their numeric Telegram chat id |
Two rules hold everywhere:
* Within one channel, that id always maps to the same contact. A customer who messages your
WhatsApp number today and again in six months is one contact, not two.
* A person has **at most one identity per channel**. You cannot end up with the same person
twice on the same WhatsApp number.
Identities are why replies go to the right place. When you answer from the
[Inbox](/inbox/overview), or a [flow](/automation/overview) sends a message, DMLY sends on
the identity that conversation belongs to — not on whichever channel happens to be listed
first on the profile.
## When one person becomes two contacts
When a message arrives, DMLY looks for an existing identity on that channel. If there is
none, it creates a new contact. It does not go looking for a match elsewhere in your
workspace by phone number or email — shared and recycled numbers would quietly merge
strangers, and a duplicate is the safer mistake.
So duplicates happen, and the cure is manual.
If DMLY can see a phone number or email in common, the profile shows a **Possible
duplicates** card: "These contacts share a phone or email with this person. Merge to
combine their channels, history and tags into one profile."
DMLY shows you which way round it goes before you commit: the duplicate is merged into
the profile you are looking at.
All of the duplicate's channels, messages, notes and tags move across, and the duplicate
is deleted.
**A merge cannot be undone.** DMLY says so in the confirmation. Check you have the two
profiles the right way round — the one you are viewing is the one that survives.
Two things a merge deliberately gets right:
* **Opt-out sticks.** If either profile had opted out of messages, the survivor is opted out.
A merge can never quietly re-subscribe someone.
* **Client status sticks.** If either profile was a client, the survivor is a client, keeping
the earlier conversion date.
If you never see a **Possible duplicates** card, the two profiles have no phone or email in
common — which is normal for a Facebook or Instagram contact. Ask the person for their
number in the chat, save it on the profile, and the duplicate becomes visible to merge.
A [CSV import](/contacts/import-csv) does the same job in bulk: a row whose phone or email
exactly matches someone you already have attaches the channel to that person instead of
creating a second copy.
## Lifecycle stage: leads and clients
Every contact has a **lifecycle stage**. It answers one question — is this person still an
enquiry, or are they doing business with you?
| Stage | Means |
| ---------- | ---------------------------------------------------------------------------------- |
| **Lead** | The default. Someone who has messaged you, been imported, or been added by hand. |
| **Client** | Someone with commercial history — an invoice, an order, a payment, a subscription. |
The list at the top of **Contacts** filters on exactly this: **All**, **Leads**, **Clients**,
**Archived**.
Two further stages exist in the data — `archived` and `inactive` — but nothing in the app
sets either one. There is no archive button on a contact, and the edit form does not touch
the lifecycle stage; only the [API](/api-reference/introduction) can set them. The
**Archived** tab is real and will count whatever the API put there, so on a workspace that
has never called the API it reads zero. A contact set to `inactive` has no tab at all and
disappears from everything except **All**.
### Clients are a filtered view, not a separate list
This is worth saying plainly because it shapes everything else: **Clients** is the same
Contacts page with the lifecycle filter set to Client. Same records, same filters, same
counts. There is no separate client database to keep in sync, and a person cannot be a
contact *and* a client — being a client is something a contact *is*.
What a client gets is more of the profile page: credits, amount due, loyalty points, lifetime
value, and tabs for invoices, orders, payments, appointments and the rest. Leads render
without any of it. See [The client profile](/contacts/client-profile).
### How a lead becomes a client
Automatically, most of the time. A contact is promoted the moment real commerce touches them:
* an invoice is created for them
* an order is created for them
* a payment is recorded against them
* a subscription starts
You do not have to remember to do it, and these never fail for a missing phone number.
Manually, with **Convert to client** on the contact page: "Convert this person into a client?
They'll be billable and gain access to invoices, orders and credits."
The manual button needs a way to reach the person first: "A client needs at least a phone
number or email so you can reach and invoice them. Add one to continue." Add a phone number
or email and convert again. Automatic conversions never stop for this.
### Going back
**Mark as lead** moves a client back — but only if there is nothing commercial on file. If
they have a confirmed booking, a successful payment, or a paid order, DMLY blocks it: "This
client has billing or booking records and can't be moved back to a lead."
Downgrading never deletes anything. The client profile, the invoices and the history all
stay; only the stage changes.
## Five things that look like the same setting and aren't
This trips people up more than anything else in the CRM. A contact carries several
independent switches, and none of them feed each other.
| What | Where you set it | What it actually does |
| -------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Lifecycle stage** | **Convert to client** / **Mark as lead** on the contact | Whether the finance side of the profile exists, and which tab they appear under |
| **Pipeline stage** | **Pipeline View**, **Pipeline stage** on the contact, a flow, or your AI agent | Your own sales process and segment targeting. Flows can branch on it, and it fires a `contact.stage_changed` webhook. It never touches lifecycle stage or billing. |
| **Status** — blocked | The [Inbox](/inbox/overview), not Contacts | Blocked contacts get no automated messages |
| **Opted out** | The contact replies `STOP`, or an automation's **Unsubscribe contact** action | Stops all automated messages. Agents can still reply by hand. Reversible from **Suppressions** with **Resubscribe**, or by the contact replying `RESUBSCRIBE`. |
| **Pause bot reply** | The contact page | Stops your bot answering this one person, so a human can take over |
**Pipeline stage is not lifecycle stage, even though the words collide.** DMLY ships three
default pipeline columns named Lead, Engaged and Customer. Dragging someone into the
**Customer** column does *not* make them a client, and converting someone to a client does
not move them out of the **Lead** column. They are separate fields that never talk to each
other. See [Pipeline stages](/contacts/pipeline-stages).
**The Archived tab is not the Inbox archive.** Archiving a conversation tidies your Inbox
folder; it does not touch the contact's lifecycle stage, and it will not put anyone in the
**Archived** tab.
Blocking and opting out are both covered in [Data and privacy](/contacts/data-and-privacy),
along with the **Suppressions** tab that lists everyone in either state.
## Two things about the list itself
* **The channel you are working in does not filter this list.** Contacts always shows every
person in the workspace. The active channel scopes your *conversations*, not your *people*.
**Channels** is there as an optional filter if you want it.
* **People who only ever left a public comment are in here.** A new commenter on a Facebook
or Instagram post gets a contact and an identity like anyone else — named from their
username where Meta exposes one, and given a placeholder like "Instagram user 5400" where it
does not. They count towards your totals. What stays separate is the conversation: comments
are threaded apart from DMs rather than folded into one thread.
## Where to go next
Label people, and build the reusable audiences your broadcasts send to.
Your own sales columns, and how to rename or reorder them.
Store the details your business needs on every contact.
Credits, invoices, loyalty and the manual actions on a client.
Bring an existing list in without creating duplicates.
Opt-outs, blocking, suppressions, export and deletion.