Skip to content

CAP-CRM-DQ-003Set the response to duplicate matches

Markdown

CAP-CRM-DQ-003

Set the response to duplicate matches

Markdown
  • DocumentDraft
  • Product intentConfirmed
  • ImplementationObserved

KindCapabilityProduct areaCRMModuleDuplicate Review and Record MergingRevision1

Read atservices-crm a8d1364freact-console baf6dae3

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes
Workspace configuration selects creation responses independently of scoring weights.Candidate review remains available under every configured response.
Surfaces
consoleapi
Intent sources
services-crm:docs/milestones/CRM-M4-duplicates-and-merge.md#D-32services-crm:docs/merging/README.md#Status (architecture and plan approved by Andrew 2026-10-11)

Controls

18 controls apply, from the corpus control catalogue.

TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-005 TC-AZ-006 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-LOG-004 TC-LOG-005 TC-PI-001 TC-PI-003 TC-PRV-001 TC-PRV-002 TC-TEN-001 TC-TEN-002 TC-TEN-003

Permissions

KeyChecked atScope
crm.duplicates.configureapitenant

Business Rules

12 rules, 9 to be proved before approval. A rule's product intent is derived from its origin: 12 confirmed by a product decision, the rest inheriting this capability's confirmed.

IdRuleKindEnforced atProvenance
01must prove
Confirmed
For the relevant record type, active rules are evaluated by position and the first matching evidence pattern whose confidence floor is met determines the action.
origin: services-crm:docs/merging/README.md#Status (architecture and plan approved by Andrew 2026-10-11)
no proof recorded yet
policyservicetest
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
02must prove
Confirmed
Review, warn and block all retain candidates for review; warn also informs creation checks and block refuses ordinary creation without hiding or retiring the pair.
no proof recorded yet
policyservicetest
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)
03must prove
Confirmed
When no rule qualifies, including when none exists for the record type, the pair remains available for review.
no proof recorded yet
policyservicetest
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
04must prove
Confirmed
E-mail rules require shared e-mail evidence; name-and-postal rules require both name agreement and place agreement; name-and-phone rules require name agreement and a shared number; organization-name-and-domain rules require both kinds of agreement.
no proof recorded yet
calculationservicetest
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
05must prove
Confirmed
The minimum band sets the score floor, with medium used when the configured band is absent or unrecognized.
no proof recorded yet
validationservicetest
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
06must prove
Confirmed
Rule replacement requires the current version and matching identity and rejects stale or missing versions, invalid actions and locked rules.
no proof recorded yet
validationapi, servicetest
services-crm:modules/duplicates/tests/e2e/duplicates.e2e.spec.js#refuses the version that has moved on (409)
07must prove
Confirmed
Each workspace rule requires a distinct integer position from 1 to 100 and a trimmed, nonempty name.
no proof recorded yet
validationservice, databasetest
08must prove
Confirmed
Workspace setup supplies Contact Email Match with block and the portal switch, Contact Name and ZIP with warn, and Organization Website Match with review; repeat setup preserves edits, and the API offers neither rule creation nor deletion.
no proof recorded yet
lifecycleservicetest
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
09must prove
Confirmed
Only duplicate-configuration permission holders may read or update rules; duplicate readers and reviewers without that permission are refused.
origin: services-crm:docs/merging/architecture.md#9. Security and tenant isolation
no proof recorded yet
permissionapitest
services-crm:modules/duplicates/tests/e2e/duplicates.e2e.spec.js#answers 403 to a reviewer reading the rules, which are the tenant’s configuration
10
Confirmed
The saved portal switch does not influence portal sign-up matching, which does not read workspace duplicate rules.
policyservicedocumented
services-crm:docs/merging/duplicate-detection.md#15. Portal sign-up (the `portal_sign_up` origin)
11
Confirmed
Updating a rule leaves existing candidates unevaluated until subsequent record changes or a re-check applies the new settings.
policyserviceobserved
12
Confirmed
Workspace data exports include duplicate-rule configuration.
policyserviceobserved

Scenarios

IdGivenWhenThenProvenance
01Two e-mail rules qualify, with warning placed ahead of the seeded blocker.Staff create a contact sharing an existing e-mail.Creation proceeds with warning and a review pair; restoring blocker precedence refuses another create.test
02An existing workspace pair qualifies under a blocker.Detection scores it again.The pair remains open and reviewable under its original identity.test

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.