Skip to content

ATS-CRM-DQ-003Set the response to duplicate matches: Capability Test Specification

Markdown

ATS-CRM-DQ-003

Set the response to duplicate matches: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-CRM-DQ-003

Design

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

KindAcceptance test setProduct areaCRMModuleDuplicate Review and Record MergingRevision1

Read atservices-crm a8d1364freact-console baf6dae3

Coverage

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

Test Scenarios

12 scenarios proving CAP-CRM-DQ-003; 10 bound to an existing test.

01 Rule order respects activity and record typeruleunittest
Proves
BR-CAP-CRM-DQ-003-01
Preconditions
Mix contact and organization rules, an inactive rule and two qualifying positions.
Steps
Evaluate a matching pair.
Expected
The first active qualifying rule for its type determines the action.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/duplicates/tests/unit/services/detection/duplicate-rule-actions.spec.js#is decided by the first matching rule in position order, not by a later one that also matches
services-crm:modules/duplicates/tests/unit/services/detection/duplicate-rule-actions.spec.js#leaves out a rule that is turned off, which is what the screen’s toggle means
services-crm:modules/duplicates/tests/unit/services/detection/duplicate-rule-actions.spec.js#leaves out a rule of the other record type, so an organization rule never decides a contact pair
Source
services-crm:modules/duplicates/tests/unit/services/detection/duplicate-rule-actions.spec.js#is decided by the first matching rule in position order, not by a later one that also matches
02 Blocking retains the review candidateinvariantapitest
Proves
BR-CAP-CRM-DQ-003-02
Preconditions
Configure a blocking rule that matches a pair.
Steps
Detect and refresh that pair.
Expected
The open pair remains stored under the same identity.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/unit/services/detection/duplicate-rule-actions.spec.js#stores the candidate for a block rule too, the block acting at the create and never on the queue (D-32)
03 Unmatched rules leave a suggestion reviewableedgeunittest
Proves
BR-CAP-CRM-DQ-003-03
Preconditions
First provide no applicable rules, then provide nonmatching rules.
Steps
Evaluate the pair in both cases.
Expected
Both evaluations retain the candidate for review.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/duplicates/tests/unit/services/detection/duplicate-rule-actions.spec.js#keeps a pair no rule matches for review, which is detection’s default
services-crm:modules/duplicates/tests/unit/services/detection/duplicate-rule-actions.spec.js#keeps a pair for review when the tenant has no rule of this record type at all
Source
services-crm:modules/duplicates/tests/unit/services/detection/duplicate-rule-actions.spec.js#keeps a pair no rule matches for review, which is detection’s default
04 Evidence patterns require their named agreementsruleunittest
Proves
BR-CAP-CRM-DQ-003-04
Preconditions
Prepare pairs with and without e-mail, name, place, phone and domain agreement.
Steps
Evaluate all configured match kinds.
Expected
Each requires its stated evidence; name disagreement cannot satisfy name-and-postal matching and domain alone cannot satisfy name-and-domain matching.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/duplicates/tests/unit/services/detection/duplicate-rule-actions.spec.js#does not match on name and postal code when a name DISAGREES, however the places compare
services-crm:modules/duplicates/tests/unit/services/detection/duplicate-rule-actions.spec.js#matches on name and phone when a name agrees and a number is shared
services-crm:modules/duplicates/tests/unit/services/detection/duplicate-rule-actions.spec.js#does not match on organization name and domain when only the domain agrees
Source
services-crm:modules/duplicates/tests/unit/services/detection/duplicate-rule-actions.spec.js#does not match on name and postal code when a name DISAGREES, however the places compare
05 Confidence floors use medium as the fallbackboundaryunittest
Proves
BR-CAP-CRM-DQ-003-05
Preconditions
Supply explicit, absent and unrecognized minimum bands.
Steps
Evaluate pairs at and below their floors.
Expected
The exact floor qualifies; absent and unknown values use medium.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/duplicates/tests/unit/services/detection/duplicate-rule-actions.spec.js#matches a pair scoring exactly the rule’s band, which is the floor and not a step above it
services-crm:modules/duplicates/tests/unit/services/detection/duplicate-rule-actions.spec.js#holds a rule naming no band to the default band, which is what the column defaults to
services-crm:modules/duplicates/tests/unit/services/detection/duplicate-rule-actions.spec.js#holds a rule naming a band this release does not know to the default band, rather than matching nothing
Source
services-crm:modules/duplicates/tests/unit/services/detection/duplicate-rule-actions.spec.js#matches a pair scoring exactly the rule’s band, which is the floor and not a step above it
06 Invalid replacements preserve the existing ruleconcurrencyapinegativetest
Proves
BR-CAP-CRM-DQ-003-06
Preconditions
Read a rule and prepare stale, versionless, mismatched, invalid-action and locked replacements.
Steps
Submit each replacement.
Expected
Every invalid edit is refused and the stored rule remains unchanged.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/e2e/duplicates.e2e.spec.js#refuses the version that has moved on (409)
07 Names and ordering positions are validatedvalidationapinegativetest
Proves
BR-CAP-CRM-DQ-003-07
Preconditions
Prepare two configuration rules.
Steps
Try a duplicate position, out-of-range positions and a blank name.
Expected
Each invalid input is rejected.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/integration/services/persistence/duplicate-rules.integration.spec.js#refuses the place another rule already holds
08 Configuration authority is separate from reviewpermissionapinegativetest
Proves
BR-CAP-CRM-DQ-003-09
Preconditions
Prepare a duplicate reader, reviewer and configuration administrator.
Steps
Request rule reads and updates as each caller.
Expected
Only the caller with configuration authority succeeds.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/duplicates/tests/e2e/duplicates.e2e.spec.js#answers 403 to a reviewer reading the rules, which are the tenant’s configuration
09 Moving rule order changes creation behaviorinteractionbrowsertest
Proves
BR-CAP-CRM-DQ-003-01 BR-CAP-CRM-DQ-003-02
Preconditions
Start with the seeded settings.
Steps
Place a warning before the blocking rule, create the matching contact, restore the order and repeat.
Expected
The first create succeeds with a review pair and the second is blocked.
Data
The existing scenario setup supplies the required records.
Bound to
Source
react-console:acceptance/crm/playwright/journeys/merging/CRM-ACC-0244.spec.ts#CRM-ACC-0244
10 Two rules cannot hold the same positioninvariantapitest
Proves
INV-DOM-CRM-DQ-001-11
Preconditions
Two rules in one workspace at different positions.
Steps
Try moving the second rule to the first rule’s position.
Expected
The update is refused and the original ordering remains.
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-rules.integration.spec.js#refuses the place another rule already holds
11 Provisioning preserves an edited workspace ruletransitionapinegativeproposed
Proves
BR-CAP-CRM-DQ-003-08
Preconditions
A workspace with no default rules, followed by an edited default.
Steps
Provision defaults, edit one, provision again and inspect all rule identities and versions.
Expected
The default set exists and repeat provisioning retains the edit and its version.
Data
Run-owned records and caller permissions that distinguish the two cases.
Source
services-crm:modules/duplicates/tests/integration/services/persistence/duplicate-rules.integration.spec.js#leaves the tenant’s own name, switch and action exactly as the tenant left them
12 Configuration reaches draft checks and later re-checksinteractionapiproposed
Proves
BR-CAP-CRM-DQ-003-01 BR-CAP-CRM-DQ-003-02 BR-CAP-CRM-DQ-003-03 BR-CAP-CRM-DQ-003-04 BR-CAP-CRM-DQ-003-05 BR-CAP-CRM-DQ-003-06 BR-CAP-CRM-DQ-003-07 BR-CAP-CRM-DQ-003-09 BR-CAP-CRM-DQ-003-08
Preconditions
Run-owned contact and organization records, the relevant staff permissions and the related state described by the sequence.
Steps
Move a qualifying warning ahead of a blocking rule, check a draft, then restore the order and request a re-check of saved records.
Expected
Creation advice follows each configured order while the re-check refreshes existing review work.
Data
An isolated workspace with related records and fixed timestamps; owned participant failure injection where requested.
Source
CAP-CRM-DQ-003; CAP-CRM-DQ-004; CAP-CRM-DQ-005; WF-CRM-DQ-001; WF-CRM-DQ-002; WF-CRM-DQ-003; WF-CRM-DQ-009

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.