Tuning and Troubleshooting Duplicate Check Results in Production

Explanation

Once duplicate check is configured and live, the real work begins: production data is messier than test data, and stewards will report two recurring complaints - too many false positives (the system flags records as duplicates that are clearly different) and too many false negatives (obvious duplicates slip through). Understanding why this happens and how to tune the system without breaking governance is a core intermediate-level skill. Duplicate check in MDG typically relies on a search service that indexes key attributes (name, address, tax number, bank details, or material description depending on the object) and computes a similarity score against existing records when a create or change request is submitted. The score is compared against a configured threshold: records above the threshold are surfaced to the requester or steward as potential duplicates, usually within the change request UI before or during processing. Common root causes of false positives: - Overly broad matching fields (e.g., matching only on city and postal code for organizations with many branches at the same address). - Thresholds set too low, causing loosely similar names to trigger matches. - Address normalization inconsistencies (abbreviations like 'St.' vs 'Street') inflating or deflating similarity scores unpredictably. - Legacy data loaded without going through the duplicate check, creating near-duplicate pairs that then trigger noisy matches for every new similar record afterward. Common root causes of false negatives: - Attributes used for matching are inconsistently populated (e.g., tax number field empty for many existing vendors). - Name variations (abbreviations, transliterations, legal form suffixes like GmbH vs Ltd) not normalized before comparison. - Threshold set too high, so genuinely similar records score just below the cutoff. - Search index not refreshed after mass loads, so newly created records are invisible to the check for a period of time. Troubleshooting approach: first reproduce the issue with a specific business partner or material number pair, then examine which fields were used in the match and what score was returned, if the deployment's search results screen or match rule diagnostics expose that detail. Confirm whether the record was indexed at the time of the check - a delayed or failed indexing job is one of the most common causes of missed duplicates in initial weeks after go-live. Check whether the requester bypassed a warning-level duplicate result, since many configurations allow proceeding past a warning versus blocking on a hard match. Tuning strategy should be incremental: change one variable (a threshold, a field weight, or a normalization rule) at a time and validate against a documented set of known duplicate pairs and known non-duplicate pairs (a regression test set is invaluable here). Avoid tuning based on a single anecdotal case, since overcorrecting for one steward complaint can suppress detection for a different scenario. Deployment differences: on-premise and private cloud landscapes may allow closer inspection of search service configuration and reindexing jobs by the technical team, while public cloud tenants typically expose duplicate check tuning through more constrained, scoped configuration activities and may have fixed search service behavior that customers cannot deeply customize. Where uncertain about exact configuration scope in a specific tenant, validate directly against that system rather than assuming parity with on-premise capability. Performance is a secondary but real concern: overly complex match rules or very large candidate sets can slow down change request submission, frustrating requesters. Monitor how long duplicate checks take during peak load periods and work with the technical team to review indexing volume and search service sizing if delays become noticeable.

Code example

Example: documenting a tuning change for audit and regression purposes (illustrative record, not a specific transaction) Tuning Change Log Entry------------------------Object: Business Partner (Organization)Issue: False positives for organizations sharing a shared-office addressRoot cause: Match rule weighted postal code and city too heavily relative to organization nameChange: Reduced weight of address fields, increased weight of normalized organization name and tax numberValidation set used: 25 known duplicate pairs, 25 known non-duplicate pairs sharing addressesResult before change: 9 false positives, 0 false negativesResult after change: 1 false positive, 1 false negativeApproved by: Data Governance LeadRollback plan: Revert weighting configuration entry to prior version if false negative rate increases beyond 2 percent over next 30 days

Real project scenario

A shared-services company centralizing vendor master data noticed the duplicate check was blocking a high volume of legitimate new vendor requests because many vendors operated out of the same business park address with shared mailboxes. The data governance team pulled a sample of 40 flagged requests, confirmed 32 were false positives caused by address-heavy matching, and worked with the configuration team to rebalance the match weighting toward tax identification number and normalized legal name. They validated the change against a curated set of known duplicate and non-duplicate pairs before promoting it, and set up a recurring monthly review of duplicate check override statistics to catch any drift.

Common mistakes

• Tuning thresholds based on a single complaint without a validation data set, causing regressions elsewhere • Assuming the search index is always current immediately after mass data loads • Ignoring inconsistent population of key matching fields such as tax number or registration ID • Not distinguishing between warning-level and blocking-level duplicate results when analyzing steward behavior • Failing to document tuning changes, making it impossible to audit why a match rule behaves differently over time • Assuming cloud and on-premise duplicate check configuration options are identical without verifying in the actual tenant

Best practices

• Maintain a regression set of known duplicate and non-duplicate pairs to validate every tuning change • Change one configuration variable at a time and measure impact before combining changes • Monitor search index refresh timing after mass loads and communicate expected delays to stewards • Track override rates on duplicate warnings to detect when stewards are habitually bypassing valid signals • Document every tuning change with rationale, validation results, and a rollback plan • Verify actual configuration scope and capability in the specific target tenant rather than assuming parity across deployment types

Interview angle

Interviewers assess whether a candidate can reason about false positives versus false negatives systematically rather than anecdotally, understands that duplicate check quality depends on data field consistency as much as configuration, and knows to validate tuning changes against a regression set. Strong answers reference indexing timing issues as a root cause of missed duplicates and articulate the difference between blocking and warning-level results in a workflow.