Duplicates in Bitrix24 are repeated cards for the same client: two leads with one phone number, a contact and a company sharing an email, two deals for one enquiry. The built-in duplicate control catches matches when a card is created and can bulk-merge, but duplicates that enter the base any other way stay alive. Here is where they come from, what the stock tool covers, how to merge without losing data, and how to close the problem systematically.
Where do CRM duplicates come from?
Four sources. Repeated touches: a client fills a website form, then calls, then writes in a messenger — each channel creates its own lead. Imports: a legacy base loaded without matching against existing records. Integrations: telephony and mail create entities by their own rules and do not always see each other. Manual entry: a manager types the phone as "8 912…" while the base stores "+7 912…" — different strings to a search engine. The last case is the sneakiest: formally there is no duplicate, factually there is. That is why data normalization is half the battle: the Format phone robot standardizes numbers right inside your flows, and Format entity phones cleans the cards already saved.
What does the built-in duplicate control cover?
The stock mechanism works in three places. On card creation it warns about matches by name, phone or email. In the lead/contact/company list, the gear menu has Duplicate search: it finds groups of similar records and offers to merge each group. On import there is a "skip duplicates" option. Merging moves fields, activities, history and links into one card; conflicting values must be picked by hand. What it does not do: it does not check duplicates when a card moves through the pipeline, does not block work on a repeated entity, only compares near-identical values, and offers no custom matching rules. A duplicate that slips past the creation check lives on unnoticed.
How do I merge duplicates without losing data?
Before a mass merge: close open activities on the duplicate cards, agree which card is the "primary" (usually the oldest — it holds the history), and export the base in case you need a rollback. Then run the stock duplicate search by phone and email — the most reliable keys; review name-based merges manually, since namesakes are not duplicates. After merging, check the deals: they must point to the surviving card. Inside workflows, use the Find contact robot — before creating a new entity it looks up an existing contact by phone and returns the ID, so the flow attaches the new enquiry to the found card instead of creating a duplicate. Likewise Find deal locates the client's open deal so a repeat enquiry does not spawn a new one.
How do I stop duplicates systematically?
Manual duplicate-search runs are cleanup, not prevention. The systematic fix is checking at the moment of work: the Duplicates No More app runs the check when a manager moves a card through the pipeline or edits it, and the entity does not move on until the duplicate is merged or deleted. Add bulk scanning of the whole base and two merge modes — automatic for conflict-free records, manual review for disputed ones. Three protection layers work together: robots normalizing data at the entry point, workflows looking up existing entities before creating new ones, and Duplicates No More blocking pipeline moves until conflicts are resolved.
Checklist
Normalize phones and emails at the entry point; keep the creation-time check on; teach your workflows to search for existing cards before creating new ones; run a bulk duplicate search monthly; and for a blocking check on every stage move, install Duplicates No More from the Bitrix24 Market — the install is free.