Returning patients are not new patients: a duplicate record framework

Opening a returning patient as a new person disrupts daily communication as well as reporting. When conversations, notes, and activities are distributed across separate records, advisers cannot readily identify the current information. Zoho CRM does not recognise people through name similarity. A dependable framework begins by choosing an exact-match field, defining the checking scope, and using one consistent entry format across the team.

There are two connected but distinct tasks. First, prevent a second record carrying the same exact value; then merge copies that already exist in a controlled manner. Global search and custom views do not replace these tasks. Search locates records, while a view filters each record by its own fields. Without that distinction, a one-time cleanup does not stop the problem from returning.

How one patient becomes two records

The same person may write through another channel, or a telephone number may be entered in a different format. An adviser searched the patient's name and found two records; one held the surname used before marriage, the other held the later surname, and the treatment history was split between them. The problem came from field values and entry formats that defeated exact matching, not search settings.

The hasta-kabul pattern in the Clinical CRM Pattern Library shows one patient record on a single screen. This preview makes the need for one record visible but does not claim to resolve duplicates. The team must define the exact value that prevents another record, then assign responsibility for reviewing and merging existing copies. Search separately supports those decisions.

Choose the field that must be unique

Uniqueness is a field property and applies throughout the selected module. A module can have at most two unique fields; Leads, Contacts, custom modules, and Products can have three. Only text, email, telephone, integer, long integer, and URL types qualify. Tasks, Calls, and Meetings have no unique fields. Matching is case-insensitive, regardless of how letter case was entered.

A birth date cannot be marked unique because it is a date field. The team should select an eligible field, such as telephone or email, that can genuinely remain singular and consistently maintained. When someone attempts another record with the same unique value, Zoho prevents its creation. This check applies to manual entry, editing, related lists, web forms, imports, the mobile application, and API operations.

Extend checks from prospects to patients

Uniqueness in one module does not cover another module. Someone treated two years earlier wrote again and was questioned as though arriving for the first time; the old record remained with patients, the new record sat with patient prospects, and the two records did not see each other. This separation requires a distinct scope decision to prevent a converted person from being opened again as a prospect.

After a Leads field is marked unique, Duplicate Check Preference in Zoho CRM extends checking to converted Lead records or the Contacts module. When Contacts is selected, its unique comparison field is chosen separately. The path is Setup, Customization, Modules and Fields, Leads, Duplicate Check Preference; Change Preference in the unique field menu reaches the same setting. A duplicate arriving through a web form also goes to approval even when Lead or Contact Approval is disabled, and it enters the module only after approval. No edition threshold is specified for this preference.

Search is separate from a list

Zoho CRM has no search view or user-configurable list for expanding searchable fields. Global search covers single-line and multiline text, telephone, email, multi-select lists, numbers, long numbers, decimals, currency, percentages, auto-number, formulas, URLs, lookups, and multi-module lookups. Single-select lists, dates, date-time fields, checkboxes, and user fields are outside that fixed scope and cannot be added through search configuration.

A search requires at least three characters; encrypted fields support exact-text search only. Users can configure the result columns, with no more than ten fields in the search layout. Telephone is already included, but inconsistent formatting can defeat an exact match. Global searches cannot be saved and shared with the team. A result missing from an adviser's custom list may instead reflect that view's own filters.

What exact-match merging tools do

Zoho duplicate tools do not propose candidates from partial similarities in names or telephone numbers. De-duplicate runs from Actions in a module list view and accepts up to three fields; records merge only when values in the selected fields match exactly. The tool selects the record with the latest Last Activity Time as master. Users cannot change this choice, and one operation merges no more than three records.

Find and Merge opens from the three-dot menu on a record detail page. It searches six criteria fields with all-or-any logic; the user chooses the master and the retained value for each field. This tool also merges no more than three records in one operation. Similarity in unselected fields makes no decision. When partial similarities require review, the team must separately examine an exported record list by hand.

A merge cannot be undone

When Find and Merge completes, secondary records are permanently deleted and the operation cannot be reversed. Attachments, notes, and activities move to the master record. Its creation time and creator come from the oldest record, while transferred activities take the master record's owner. Workflow rules with deletion triggers run when a secondary record is removed. These consequences make master-record selection an operational decision, not clerical cleanup.

Because De-duplicate selects the most recently active record as master, the team must consider that result before running it. The tool keeps no report or audit view listing merged records afterward. Field conflicts are resolved manually during the operation. Assigning authority to a designated person with the relevant profile conditions preserves a consistent review standard. Only one user can run the tool in the same module at a time.

Document formats for names and numbers

Exact matching is useful when the same information follows one format at every entry. The team should document country-code use; spaces, parentheses, and hyphens; the fields for given and family names; and where a middle name belongs. A unique telephone or email value then becomes more than a technical setting. It becomes a shared working rule that everyone opening or editing records can follow consistently.

After a field is created, its type is fixed even though its name remains editable. Converting free text to a selection list requires creating a second field of the new type, moving existing values, and removing the old field from the layout. The removed field remains under Unused Fields and continues consuming the field limit. Removal can be reversed with its data, but permanent deletion cannot. Format discipline remains a team habit.

What retaining previous numbers requires

A separate previous-numbers field can be designed to preserve an old value after a number changes. However, a workflow field update cannot read the earlier value or append content to existing text; it writes only a predetermined constant or an empty value. Moving the old number into a history field therefore requires a custom function attached to the workflow. The same restriction applies to previous surnames.

This custom function is available in Zoho Enterprise and higher editions; on a lower edition, the team records a previous number or surname manually as a note. Unique-field behaviour is edition-independent. Exact edition thresholds for Duplicate Check Preference, De-duplicate, and Find and Merge are unspecified; the required customisation profile permission for unique fields and the relevant profile permissions for merging tools still apply. Unknown thresholds require verification before a proposal.

Mark and count returning patients

A selection list such as patient type can distinguish first-time and returning patients. Selection-list history tracking can be enabled for only one field per module. Its related list records when the value changed and how long the record remained at that value. Tasks, Calls, and Meetings do not provide this feature, and an edition downgrade deletes the retained history. The field choice should therefore follow the measurement purpose.

Adding, renaming, or deleting a value in a local selection list affects records using that value. With a globally linked set, a deleted value remains on existing records and Replace Values disappears. A custom view can filter on patient type, but it cannot compare records, create reminders, open tasks, or assign owners. Dependable counting rests on maintaining both a single patient record and consistent classification.

Zoho CRM for clinics