Prevent duplicate clients with Deduplication Control
Each unit has a rule that decides what happens when a client who already exists arrives again: a new record with a flag, a merge into the old record, a mirror of the chats, or a note on it.
Deduplication control is a paid add-on that shows with an Add-on badge in permissions, and its screen may not show in every account.
Before you start · for ownersThe permission to edit deduplication rules
- You need: The permission to edit deduplication rules
Steps
When does the rule run?
On every way a record is created: incoming chats, the web and mobile apps, adding a row in a table or Kanban, public forms, automations, the assistant, and the API.
The only exception: using Duplicate on a record by hand. The copy is always created, and only a duplicate warning shows.
How are numbers and emails normalized before they’re compared? See How does Corteksa know a client is a duplicate? Matching fields and normalization.
How do you see duplicates?
- A Possible duplicate flag on the record and in the table, with the matching records. It shows only to the owner and to roles with the permission to see duplicate warnings.
- Every decision is written in the change log with its reason: merged, created and flagged, or created as new.
- When records are merged, the message “Merged into an existing record” shows.
Paths with their own rules
Lead ad forms have their own duplicate policy in the form’s setup. And import has an option to update the records that match on one field, and uses the same normalization.
At a glance
If something goes wrong
A real example
A patient messages from their number, then books through the website form, so they show up twice.
- A rule on the “Patients” unit: match on the WhatsApp number or the email, in Unify mode.
All of the patient’s data is gathered in one record, and nothing a teammate wrote is replaced.