Skip to content

Duplicate detection

Duplicate detection helps users review records that may represent the same business object. A configurator creates a matching profile for one record type, adds exact or fuzzy rules, and chooses whether users can launch the check from a record list, a record’s Details page, or both.

Moltaro does not merge, delete, or block records automatically. A user reviews the returned candidates and decides what to do next.

Open Constructor > Duplicate detection, select a record type, and create a profile. Fields inside one rule must all match; separate enabled rules are alternatives.

An Exact normalized rule compares normalized values:

  • email ignores case and surrounding whitespace;
  • phone ignores punctuation and requires at least seven digits;
  • text key ignores case, surrounding whitespace, and repeated spaces;
  • date compares the stored calendar date.

A Fuzzy rule contains at least one fuzzy text field. It may also contain exact guard fields. For example, an exact customer type or country can prevent similar names in another business scope from being returned.

Fuzzy comparison is available for String and Text fields with the TextKey normalizer. Configure each fuzzy field with:

  • maximum edit distance from 1 to 3;
  • minimum text length;
  • weight from 1 to 100;
  • preserved or ignored diacritics;
  • ordered tokens or tokens compared in any order.

Moltaro uses Unicode-aware Damerau-Levenshtein distance. It recognizes bounded insertions, deletions, substitutions, and adjacent transpositions. Ignoring diacritics removes Unicode combining marks; it is not transliteration. Ł and L, for example, are still different unless Unicode itself decomposes the character. Any order sorts whitespace-separated tokens and preserves duplicates. Punctuation remains significant.

Every fuzzy field must pass its own distance and minimum-length settings. A highly similar field cannot compensate for another field that fails. Weights affect the effective rule score only after all required fields pass. The profile’s minimum score and confidence thresholds are then applied to the effective group score. These values are deterministic match indicators, not statistical probabilities.

Empty or invalid required values do not match. A readable value that exceeds a hard safety limit fails the run without exposing the value, record id, or hidden match count.

Exact rules can create a group containing two or more records with the same normalized key. Fuzzy matching always returns an honest pair of exactly two records. If A is similar to B and B is similar to C, but A is not similar to C, Moltaro shows A+B and B+C—not an invented A+B+C cluster.

If several rules find the same pair, the drawer shows one pair with all matched rules. It displays the effective score and confidence plus safe evidence such as distance, threshold, similarity, and weight. Raw and normalized matching values are not returned as matching evidence.

The Details page runs a complete anchored check over every active or archived record the current user can read. It is not limited to the first page or the first 250 visible records. Exact rules use an optimized database candidate query; fuzzy rules stream bounded readable values and apply the same matching contract used by full scans.

The successful result is complete and shows either matching groups/pairs or a complete empty state. At most 250 distinct candidates can be reviewed in one anchored result. If there are more, Moltaro stops without returning partial groups and reports that the anchored match is too broad. Narrow the rules before retrying.

Moltaro also stops with a retryable availability error if the complete request exceeds its five-second execution budget. The result drawer shows the localized server message. Closing the drawer or cancelling the client request cancels the work and does not return a partial result.

The first Table page check remains deliberately fast and bounded: it scans at most 250 actor-visible records and labels the result as partial whenever more visible records exist. Constructor previews use the same bounded behavior. A partial empty result does not prove that the full record type contains no duplicates.

If fuzzy rules would produce more groups than a safe interactive response can hold, Moltaro rejects the preview without showing a truncated result. Refine the rules or use the durable full scan after narrowing the configuration.

From a partial Table result, select Scan all records to enqueue a complete scan. The request returns immediately; the existing Worker Host performs exact and fuzzy matching in the background and the same drawer shows queued, counting, matching, saving, completed, failed, or cancelled state. You may close the drawer or reload the Table page. Reopen duplicate detection to recover the latest saved scan for the same profile and active/archive scope.

A completed full scan covers the complete actor-visible point-in-time scope and replaces partial groups. Candidate groups and long candidate lists are paged from the saved result. The Table page launcher and group review remain desktop-only; mobile record cards do not expose these target-wide operations.

Full scans have finite execution, comparison, memory, and retained-result budgets. A very broad or pathological result fails without publishing partial groups. A transiently failed scan can retry; cancellation is explicit. Moltaro does not start scheduled scans automatically and does not add a separate job center for duplicate detection.

One complete full scan supports up to eight enabled rules, up to four fields in each rule, and up to sixteen distinct matching fields in total. The settings screen validates fuzzy profiles against the rule bound and validates every fuzzy field setting. A legacy exact profile outside the full-scan shape can still run a bounded review but cannot enqueue a complete scan.

Duplicate detection uses the same record and field read rules as the rest of Moltaro. Inaccessible records and unreadable matching fields do not contribute to a result. Unreadable large values are not length-inspected or transferred. Error responses do not reveal hidden record ids, raw or normalized field values, or the number of hidden matches.

The full scan is pinned to the requesting user and the profile, entity, access, and archive scope that were current when it was queued. Moltaro rechecks access before processing, immediately before publishing success, and whenever a saved result is opened. If access, matching configuration, the entity definition, or a candidate record changes, the old result becomes unavailable instead of being shown partially or with stale data. Unrelated record changes can continue while the Worker scans; the result is a coherent point-in-time review rather than a workspace-wide write lock.

Duplicate detection does not provide semantic or vector similarity, nickname dictionaries, transliteration, language-specific phonetics, scheduled scans, automatic merge, or create/edit blocking. Record merge, where enabled separately, remains an explicit reviewed action.