Rhythm 2.0 Specifications

Appearance

ATS-CRM-DQ-001Detect duplicate records after changes: Capability Test Specification

Markdown

ATS-CRM-DQ-001

Detect duplicate records after changes: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-CRM-DQ-001

Design

Executed by
TST-CRM-DQ-176, TST-CRM-DQ-180

KindAcceptance test setProduct areaCRMModuleDuplicate Review and Record MergingRevision1

Read atservices-crm a8d1364freact-console baf6dae3

Detect duplicate records after changes: 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 RuleScenarios
BR-CAP-CRM-DQ-001-01ATS-CRM-DQ-001-01, ATS-CRM-DQ-001-11, ATS-CRM-DQ-001-20
BR-CAP-CRM-DQ-001-02ATS-CRM-DQ-001-02, ATS-CRM-DQ-001-11, ATS-CRM-DQ-001-20
BR-CAP-CRM-DQ-001-03ATS-CRM-DQ-001-03, ATS-CRM-DQ-001-20
BR-CAP-CRM-DQ-001-04ATS-CRM-DQ-001-04, ATS-CRM-DQ-001-20
BR-CAP-CRM-DQ-001-05ATS-CRM-DQ-001-05, ATS-CRM-DQ-001-20
BR-CAP-CRM-DQ-001-06ATS-CRM-DQ-001-06, ATS-CRM-DQ-001-12, ATS-CRM-DQ-001-20
BR-CAP-CRM-DQ-001-07ATS-CRM-DQ-001-07, ATS-CRM-DQ-001-11, ATS-CRM-DQ-001-14, ATS-CRM-DQ-001-20
BR-CAP-CRM-DQ-001-08ATS-CRM-DQ-001-08, ATS-CRM-DQ-001-13, ATS-CRM-DQ-001-20
BR-CAP-CRM-DQ-001-09ATS-CRM-DQ-001-09, ATS-CRM-DQ-001-20
BR-CAP-CRM-DQ-001-10ATS-CRM-DQ-001-01, ATS-CRM-DQ-001-20
BR-CAP-CRM-DQ-001-12ATS-CRM-DQ-001-10, ATS-CRM-DQ-001-20

Import the records and monitor group creation. Create two comparable contacts, dismiss their pair, edit only a name, then re-check and add shared strong evidence. Read scores, standing and group membership after each pass.

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.

Coverage

  • Rule covered
  • Transition covered
  • Validation gap: FND-CRM-DQ-052
  • Permission not-applicable
  • Edge covered
  • Failure covered
  • Boundary covered
  • Concurrency gap: FND-CRM-DQ-052
  • Invariant covered
  • Interaction covered

Test Scenarios

20 scenarios proving CAP-CRM-DQ-001; 12 bound to an existing test.

01 Detection failure leaves saving independentfailureapinegativeproposed
Proves
BR-CAP-CRM-DQ-001-01 BR-CAP-CRM-DQ-001-10
Preconditions
Arrange a contact save whose later detection pass fails.
Steps
Save the record and allow background detection to fail.
Expected
The save succeeds independently; failed processing is redelivered and keys are established only by a successful pass.
Data
Provide fixtures for arrange a contact save whose later detection pass fails.
Source
FND-CRM-DQ-027
02 Matching edits trigger refreshruleunittest
Proves
BR-CAP-CRM-DQ-001-02
Preconditions
Supply surname and job-title change events.
Steps
Apply the event filter and handler to both.
Expected
Surname processing proceeds, while the job-title event writes no keys.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/unit/services/detection/duplicate-change-events.spec.js#is not touched by a changed job title, which changes no key and no evidence
03 Contact and organization keys cover their supported evidenceruleunittest
Proves
BR-CAP-CRM-DQ-001-03
Preconditions
Prepare both types with values for every key kind.
Steps
Generate their match keys.
Expected
Six contact and five organization kinds appear, excluding free-mail domains.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/unit/services/matching/match-keys.spec.js#names the six contact key types of §3
04 Rare evidence still joins a pair when common keys are excludedboundaryapitest
Proves
BR-CAP-CRM-DQ-001-04
Preconditions
Three contacts share name and birth date; only two share a phone, with the test cap set to two.
Steps
Detect the contacts together.
Expected
The common name keys are skipped, the phone connects its pair and skipped evidence contributes zero points.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/integration/services/detection/duplicate-detection.integration.spec.js#still found the two records a rarer key joins, which is the telephone number only they hold
05 Excessively common evidence retires suggestions without undoing decisionstransitionapitest
Proves
BR-CAP-CRM-DQ-001-05
Preconditions
Prepare phone-supported pairs, an independently e-mail-supported pair and a dismissed phone pair.
Steps
Add enough phone holders to exceed the cap and detect another holder.
Expected
The phone-only open pair disappears, the e-mail pair receives updated zero-point evidence and dismissal remains untouched.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/integration/services/detection/duplicate-detection.integration.spec.js#retired the pair the number alone joined, its only evidence being disqualified
06 Records created together become one candidateedgeapitest
Proves
BR-CAP-CRM-DQ-001-06
Preconditions
Create two matching contacts in a single batch.
Steps
Run detection for the complete batch.
Expected
Keys precede comparison and one candidate connects the contacts.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/integration/services/detection/duplicate-detection.integration.spec.js#found the two records of the batch in each other, which no lookup outside the batch could have done
07 Lost resemblance removes only open detected suggestionstransitionapitest
Proves
BR-CAP-CRM-DQ-001-07
Preconditions
A contact has open detected, dismissed and confirmed pairs.
Steps
Remove its matching evidence and run detection.
Expected
Only its open detected pair disappears.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/integration/services/persistence/duplicate-candidates.integration.spec.js#removes exactly the pairs whose other record no longer scores
08 Refreshing evidence preserves pair identity and review decisionsinvariantapitest
Proves
BR-CAP-CRM-DQ-001-08
Preconditions
Prepare an existing pair and a dismissed variant.
Steps
Score them again using changed evidence.
Expected
Identity and initial detection time remain; score and band update while dismissal and its fingerprint persist.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/integration/services/persistence/duplicate-candidates.integration.spec.js#is the same row, with the same id: one pair is one candidate however often it is scored
09 Linked employer details do not pair employeesedgeapitest
Proves
BR-CAP-CRM-DQ-001-09
Preconditions
Two contacts link their work phone and address from one organization.
Steps
Run detection for both contacts.
Expected
The linked details create no matching keys or candidate.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/integration/services/detection/duplicate-detection.integration.spec.js#keys neither the linked number nor the linked address’s postal code, which are the organization’s
10 Another workspace remains outside detectionboundaryapinegativetest
Proves
BR-CAP-CRM-DQ-001-12
Preconditions
Prepare a contact owned by a different workspace.
Steps
Request detection of that identity in the current workspace.
Expected
The pass returns and stores no matching record or pair.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/integration/services/detection/duplicate-detection.integration.spec.js#answers a pass over a record of ANOTHER tenant with nothing, the tenant being the execution’s
11 Imported duplicates reach the queue without delaying savesinteractionbrowsertest
Proves
BR-CAP-CRM-DQ-001-01 BR-CAP-CRM-DQ-001-02 BR-CAP-CRM-DQ-001-07
Preconditions
Prepare a 500-person import containing fifty duplicates.
Steps
Import the records and monitor group creation.
Expected
Import timing remains acceptable and the resulting group totals match the fixture.
Data
Provide fixtures for prepare a 500-person import containing fifty duplicates.
Bound to
Source
react-console:acceptance/crm/playwright/journeys/merging/CRM-ACC-0276.spec.ts#CRM-ACC-0276
12 Observe absent becoming open after qualifying detection or declined portal registration creates a pairtransitionapiproposed
Proves
BR-CAP-CRM-DQ-001-06 INV-DOM-CRM-DQ-001-07
Preconditions
Arrange absent standing with the transition guard satisfied: The records share an eligible key, or registration supplies a declined candidate.
Steps
Qualifying detection or declined portal registration creates a pair.
Expected
Read the open standing and inspect the associated changes: persist scored evidence and its fingerprint; refresh grouping with the pair write.
Data
Fixtures for absent, the guard and the affected records; a fixed clock for time-dependent changes.
Source
services-crm:modules/duplicates/tests/integration/services/detection/duplicate-detection.integration.spec.js#found the two records of the batch in each other, which no lookup outside the batch could have done
13 Observe open becoming open after another detection pass finds the pair againtransitionapiproposed
Proves
BR-CAP-CRM-DQ-001-08
Preconditions
Arrange open standing with the transition guard satisfied: Shared eligible evidence still reaches the storage floor.
Steps
Another detection pass finds the pair again.
Expected
Read the open standing and inspect the associated changes: replace scoring fields and evaluation time; preserve identity, origin and initial detection.
Data
Fixtures for open, the guard and the affected records; a fixed clock for time-dependent changes.
Source
services-crm:modules/duplicates/tests/integration/services/persistence/duplicate-candidates.integration.spec.js#keeps the moment the pair was first detected, which no re-score owns
14 Observe open becoming absent after detection no longer finds a qualifying comparisontransitionapiproposed
Proves
BR-CAP-CRM-DQ-001-07
Preconditions
Arrange open standing with the transition guard satisfied: Only an open pair originating from detection can be retired.
Steps
Detection no longer finds a qualifying comparison.
Expected
Read the absent standing and inspect the associated changes: remove the pair; refresh affected groups and remove undersized components.
Data
Fixtures for open, the guard and the affected records; a fixed clock for time-dependent changes.
Source
services-crm:modules/duplicates/tests/integration/services/detection/duplicate-detection.integration.spec.js#retired the pair the number alone joined, its only evidence being disqualified
15 Reversed comparison input cannot create another pairinvariantapiproposed
Proves
INV-DOM-CRM-DQ-001-01
Preconditions
Two same-workspace contacts with reversed ordering and a duplicate comparison payload.
Steps
Insert the pair in both orders and attempt a duplicate direct database row.
Expected
One canonical pair is stored; duplicate direct insertion is refused.
Data
Records, versions and caller contexts owned by the run; transaction failure injection when the invariant concerns rollback.
Source
services-crm:modules/duplicates/db/duplicate-candidates.table.ts:candidateConstraints
16 Rescoring keeps the comparison’s original identityinvariantapiproposed
Proves
INV-DOM-CRM-DQ-001-04
Preconditions
A scored pair with recorded identity, origin and first-detection time.
Steps
Score it again with different evidence and read its identity fields.
Expected
The original identity fields remain unchanged while the new scoring data is visible.
Data
Records, versions and caller contexts owned by the run; transaction failure injection when the invariant concerns rollback.
Source
services-crm:modules/duplicates/services/persistence/duplicate-candidates.ts:upsertDuplicateCandidates
17 Lost resemblance removes only the undecided detected pairinvariantapitest
Proves
INV-DOM-CRM-DQ-001-05
Preconditions
Three comparisons for a record: open detected, dismissed and manually confirmed.
Steps
Remove the other record from the set of qualifying scores and inspect all three comparisons.
Expected
Only the open detected comparison disappears.
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/integration/services/persistence/duplicate-candidates.integration.spec.js#removes exactly the pairs whose other record no longer scores
18 A record in another workspace contributes no comparisonsinvariantapitest
Proves
INV-DOM-CRM-DQ-001-14
Preconditions
A contact identity belonging only to another workspace.
Steps
Run detection under the current workspace context for that identity.
Expected
The pass returns no local matching work or comparison.
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/integration/services/detection/duplicate-detection.integration.spec.js#answers a pass over a record of ANOTHER tenant with nothing, the tenant being the execution’s
19 Duplicate-processing records do not acquire custom-value stateinvariantapiproposed
Proves
INV-DOM-CRM-DQ-001-15
Preconditions
The declared matching and review record models.
Steps
Inspect their storage and registration declarations for a custom-value facet.
Expected
No custom-value state is declared for those processing records.
Data
Records, versions and caller contexts owned by the run; transaction failure injection when the invariant concerns rollback.
Source
services-crm:modules/duplicates (no metadata object registration; db/*.table.ts declares no custom-value table)
20 Refresh a reviewed pair through scoring and re-checkinginteractionapiproposed
Proves
BR-CAP-CRM-DQ-001-01 BR-CAP-CRM-DQ-001-10 BR-CAP-CRM-DQ-001-02 BR-CAP-CRM-DQ-001-03 BR-CAP-CRM-DQ-001-04 BR-CAP-CRM-DQ-001-05 BR-CAP-CRM-DQ-001-06 BR-CAP-CRM-DQ-001-07 BR-CAP-CRM-DQ-001-08 BR-CAP-CRM-DQ-001-09 BR-CAP-CRM-DQ-001-12
Preconditions
Run-owned contact and organization records, the relevant staff permissions and the related state described by the sequence.
Steps
Create two comparable contacts, dismiss their pair, edit only a name, then re-check and add shared strong evidence. Read scores, standing and group membership after each pass.
Expected
The observed scores, reopening decision and review membership agree with the named rules.
Data
An isolated workspace with related records and fixed timestamps; owned participant failure injection where requested.
Source
CAP-CRM-DQ-001; CAP-CRM-DQ-002; CAP-CRM-DQ-003; CAP-CRM-DQ-005; CAP-CRM-DQ-008; WF-CRM-DQ-001; WF-CRM-DQ-002

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software