ATS-CRM-DQ-002 Explain the strength of a duplicate suggestion: Capability Test Specification
Markdown Design / CRM / Duplicate Review and Record Merging / Locate and Prevent Duplicate Records / Capability Test Specification Explain the strength of a duplicate suggestion: Capability Test Specification Coverage The rule matrix names the authored checks. A covered category means that a scenario exists; it does not report a passing execution. The coverage notes and findings identify missing checks, while execution sources retain the exact assertions inspected.
Required Rule Scenarios BR-CAP-CRM-DQ-002-01ATS-CRM-DQ-002-01 , ATS-CRM-DQ-002-08 , ATS-CRM-DQ-002-11BR-CAP-CRM-DQ-002-02ATS-CRM-DQ-002-02 , ATS-CRM-DQ-002-11BR-CAP-CRM-DQ-002-03ATS-CRM-DQ-002-03 , ATS-CRM-DQ-002-11BR-CAP-CRM-DQ-002-04ATS-CRM-DQ-002-04 , ATS-CRM-DQ-002-08 , ATS-CRM-DQ-002-11BR-CAP-CRM-DQ-002-05ATS-CRM-DQ-002-05 , ATS-CRM-DQ-002-08 , ATS-CRM-DQ-002-11BR-CAP-CRM-DQ-002-06ATS-CRM-DQ-002-06 , ATS-CRM-DQ-002-11BR-CAP-CRM-DQ-002-08ATS-CRM-DQ-002-07 , ATS-CRM-DQ-002-11BR-CAP-CRM-DQ-002-12ATS-CRM-DQ-002-02 , ATS-CRM-DQ-002-11BR-CAP-CRM-DQ-002-13ATS-CRM-DQ-002-09 , ATS-CRM-DQ-002-11
Review their Data Quality suggestions. Score matching and contradictory contact variants, evaluate the configured action for each, and open their queue explanations.
These sequences test the handoffs named in the interaction coverage record. A proposed sequence remains unbound until an executable run checks its combined outcome; component assertions alone leave that obligation open.
Show evidence (sources, provenance, origins, pinned commits)Coverage Rule covered Transition gap: FND-CRM-DQ-053 Validation gap: FND-CRM-DQ-053 Permission gap: FND-CRM-DQ-053 Edge covered Failure gap: FND-CRM-DQ-053 Boundary covered Concurrency gap: FND-CRM-DQ-053 Invariant covered Interaction covered Test Scenarios 11 scenarios proving CAP-CRM-DQ-002 ; 10 bound to an existing test.
03 Organization evidence applies its weights and ceilings rule unit test
Proves BR-CAP-CRM-DQ-002-03 Preconditions Prepare each organization evidence type, a domain-only resemblance and an ancestor pair. Steps Score the fixtures. Expected Points follow the schedule, domain-only resemblance caps at 69 and ancestry at 35. Data The existing scenario setup supplies the required records. Bound to Source services-crm:modules/duplicates/tests/unit/services/matching/bands.spec.js #declares the weight of every row of §5.2 04 Band boundaries distinguish stored suggestions boundary unit test
Proves BR-CAP-CRM-DQ-002-04 Preconditions Use scores 0, 34, 35, 49, 50, 69, 70, 89, 90 and 100. Steps Resolve the confidence band for each score. Expected Values below 35 have no band; the remaining boundaries produce low, medium, high and very high correctly. Data The existing scenario setup supplies the required records. Bound to Source services-crm:modules/duplicates/tests/unit/services/matching/bands.spec.js #gives 34 no band at all, so the pair is not stored 05 Reasons explain points before score ceilings rule unit test
Proves BR-CAP-CRM-DQ-002-05 Preconditions A pair contains several evidence contributions and a score limit. Steps Render the explanation. Expected Reasons follow scoring order with their points, followed by the ceiling explanation. Data The existing scenario setup supplies the required records. Bound to Source services-crm:modules/duplicates/tests/unit/services/matching/explanation.spec.js #renders one sentence per piece of evidence, in the order the scorer found it 06 Explanations mask private matching values invariant unit negative test
Proves BR-CAP-CRM-DQ-002-06 Preconditions A pair agrees on e-mail, phone and birth date. Steps Generate the masked evidence explanation. Expected E-mail retains only its first character and domain, phone its last four digits and no full birth date appears. Data The existing scenario setup supplies the required records. Bound to Source services-crm:modules/duplicates/tests/unit/services/matching/explanation.spec.js #never carries a full e-mail address into a sentence 09 Evidence totals remain bounded boundary unit test
Proves BR-CAP-CRM-DQ-002-13 Preconditions Prepare pairs with excess positive evidence and conflicting evidence. Steps Score each pair and inspect the final total and applied ceilings. Expected Totals remain between zero and 100 and respect the lowest ceiling. Data Use the records and caller described in this scenario. Bound to Source services-crm:modules/duplicates/services/matching/scoring.ts :scoreOf 10 The confidence floor separates two adjacent scores invariant unit test
Proves INV-DOM-CRM-DQ-001-02 Preconditions Pairs with computed scores of thirty-four and thirty-five. Steps Assign a confidence band to each score. Expected The lower score has no band; the higher score receives the low band. Data Records, versions and caller contexts owned by the run; transaction failure injection when the invariant concerns rollback. Bound to Source services-crm:modules/duplicates/tests/unit/services/matching/bands.spec.js #gives 34 no band at all, so the pair is not stored ← Previous Capability Test Specification ATS-CRM-DQ-001 · Detect duplicate records after changes: Capability Test Specification Next Capability Test Specification → ATS-CRM-DQ-003 · Set the response to duplicate matches: Capability Test Specification