Rhythm 2.0 Specifications

Appearance

ATS-CRM-DQ-014Preserve the right information on the surviving contact: Capability Test Specification

Markdown

ATS-CRM-DQ-014

Preserve the right information on the surviving contact: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-CRM-DQ-014

Design

Executed by
TST-CRM-DQ-176, TST-CRM-DQ-181, TST-CRM-DQ-183

KindAcceptance test setProduct areaCRMModuleDuplicate Review and Record MergingRevision1

Read atservices-crm a8d1364freact-console baf6dae3

Preserve the right information on the surviving contact: 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-014-01ATS-CRM-DQ-014-01, ATS-CRM-DQ-014-14, ATS-CRM-DQ-014-16
BR-CAP-CRM-DQ-014-02ATS-CRM-DQ-014-02, ATS-CRM-DQ-014-16
BR-CAP-CRM-DQ-014-03ATS-CRM-DQ-014-03, ATS-CRM-DQ-014-16
BR-CAP-CRM-DQ-014-04ATS-CRM-DQ-014-04, ATS-CRM-DQ-014-16
BR-CAP-CRM-DQ-014-05ATS-CRM-DQ-014-05, ATS-CRM-DQ-014-14, ATS-CRM-DQ-014-16
BR-CAP-CRM-DQ-014-06ATS-CRM-DQ-014-06, ATS-CRM-DQ-014-14, ATS-CRM-DQ-014-16
BR-CAP-CRM-DQ-014-07ATS-CRM-DQ-014-07, ATS-CRM-DQ-014-16
BR-CAP-CRM-DQ-014-08ATS-CRM-DQ-014-08, ATS-CRM-DQ-014-16
BR-CAP-CRM-DQ-014-09ATS-CRM-DQ-014-09, ATS-CRM-DQ-014-16
BR-CAP-CRM-DQ-014-10ATS-CRM-DQ-014-10, ATS-CRM-DQ-014-16
BR-CAP-CRM-DQ-014-11ATS-CRM-DQ-014-15, ATS-CRM-DQ-014-16
BR-CAP-CRM-DQ-014-12ATS-CRM-DQ-014-11, ATS-CRM-DQ-014-16
BR-CAP-CRM-DQ-014-13ATS-CRM-DQ-014-12, ATS-CRM-DQ-014-16
BR-CAP-CRM-DQ-014-14ATS-CRM-DQ-014-13, ATS-CRM-DQ-014-14, ATS-CRM-DQ-014-16

Merge through the wizard and acknowledge omissions. Choose contact detail slots and affiliations, merge the contacts, then merge their source organizations with a different retained slot. Read the surviving linked details and consent.

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 covered
  • Permission gap: FND-CRM-DQ-065
  • Edge covered
  • Failure covered
  • Boundary covered
  • Concurrency gap: FND-CRM-DQ-065
  • Invariant covered
  • Interaction covered

Test Scenarios

16 scenarios proving CAP-CRM-DQ-014; 14 bound to an existing test.

01 Consent is combined without an override choiceinvariantunittest
Proves
BR-CAP-CRM-DQ-014-01
Preconditions
Participants differ on contact prohibitions and subscriptions.
Steps
Compute the preview.
Expected
The strictest flags and subscription remain, no question permits relaxation and discarded choices identify the consent rule.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/unit/services/planning/contact-fields.spec.js#is true on the survivor when any participant holds it
services-crm:modules/merges/tests/unit/services/planning/contact-collections.spec.js#combines two preferences of one type to the most restrictive status, and offers no choice about it
services-crm:modules/merges/tests/unit/services/planning/contact-collections.spec.js#attributes the wider status it did not keep to the rule that would not widen consent
Source
services-crm:modules/merges/tests/unit/services/planning/contact-fields.spec.js#is true on the survivor when any participant holds it
02 Same-type details compete for one slotruleunittest
Proves
BR-CAP-CRM-DQ-014-02
Preconditions
Two participants hold different work addresses.
Steps
Plan and select the alternative address.
Expected
One slot question selects the written address and explains the discarded one.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/unit/services/planning/contact-collections.spec.js#writes the other address when staff choose it, and attributes the survivor’s to the slot conflict
Source
services-crm:modules/merges/tests/unit/services/planning/contact-collections.spec.js#writes the other address when staff choose it, and attributes the survivor’s to the slot conflict
03 E-mail choices respect count and primary uniquenessboundaryunitnegativetest
Proves
BR-CAP-CRM-DQ-014-03
Preconditions
Four distinct addresses compete and an outsider reserves a possible primary.
Steps
Build the plan.
Expected
Selection limits retention to three, requires a primary and blocks the reserved primary.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/unit/services/planning/contact-collections.spec.js#asks which three to keep when the participants hold more
services-crm:modules/merges/tests/unit/services/planning/contact-collections.spec.js#offers no way to leave the kept addresses without a primary
services-crm:modules/merges/tests/unit/services/planning/contact-collections.spec.js#blocks the merge when the primary address belongs to a contact outside the merge
Source
services-crm:modules/merges/tests/unit/services/planning/contact-collections.spec.js#asks which three to keep when the participants hold more
04 Preferred addresses exclude seasonal choicesvalidationunittest
Proves
BR-CAP-CRM-DQ-014-04
Preconditions
Two preferred addresses compete, including a seasonal address.
Steps
Compute their plan.
Expected
The selected preference follows the survivor default and cannot be seasonal.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/unit/services/planning/contact-collections.spec.js#writes exactly one preferred address when two participants each flagged one
services-crm:modules/merges/tests/unit/services/planning/contact-collections.spec.js#never prefers a seasonal address, which the table refuses
Source
services-crm:modules/merges/tests/unit/services/planning/contact-collections.spec.js#writes exactly one preferred address when two participants each flagged one
05 Deceased status needs a deliberate answervalidationunittest
Proves
BR-CAP-CRM-DQ-014-05
Preconditions
One participant is deceased and another is living.
Steps
Build the plan.
Expected
An unanswered required status question has no default and prevents readiness.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/unit/services/planning/contact-fields.spec.js#asks a required question when one participant is deceased and another is not
services-crm:modules/merges/tests/unit/services/planning/contact-fields.spec.js#offers that question no default, because neither state may be assumed
services-crm:modules/merges/tests/unit/services/planning/contact-fields.spec.js#holds the plan at needs_decisions until that question is answered
Source
services-crm:modules/merges/tests/unit/services/planning/contact-fields.spec.js#asks a required question when one participant is deceased and another is not
06 Participant spouse links cannot become self-linksedgeunittest
Proves
BR-CAP-CRM-DQ-014-06
Preconditions
An absorbed participant names the survivor as spouse.
Steps
Compute the preview.
Expected
The spouse reference clears with its responsible rule identified.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/unit/services/planning/contact-fields.spec.js#is cleared when the survivor itself is the spouse a participant names, which no contact may be
services-crm:modules/merges/tests/unit/services/planning/contact-fields.spec.js#attributes the cleared spouse to the rule that cleared it
Source
services-crm:modules/merges/tests/unit/services/planning/contact-fields.spec.js#is cleared when the survivor itself is the spouse a participant names, which no contact may be
07 Equivalent employment stays combine without collapsing distinct staysruleapitest
Proves
BR-CAP-CRM-DQ-014-07
Preconditions
Prepare overlapping Acme affiliations and two separate stays elsewhere.
Steps
Run the planned contact combination.
Expected
The Acme stay uses its earliest start and both role sets while distinct stays remain separate.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/merges/tests/integration/services/merges/merge-execution.integration.spec.js#combines the two Acme affiliations into one, from the earliest start, open, with the survivor’s title and both roles
08 Primary affiliations use only effective choicesedgeunittest
Proves
BR-CAP-CRM-DQ-014-08
Preconditions
Prepare competing primaries, a survivor without one and ended or future affiliations.
Steps
Build previews.
Expected
Competing primaries create an optional defaulted choice, a sole absorbed primary fills the gap and ineffective affiliations are excluded.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/unit/services/planning/contact-collections.spec.js#shows the primary organization for review as a defaulted, optional decision when two participants hold one at different organizations
services-crm:modules/merges/tests/unit/services/planning/contact-collections.spec.js#keeps the merged contact’s primary as the primary organization when the survivor has none, without asking
services-crm:modules/merges/tests/unit/services/planning/contact-collections.spec.js#never offers an ended affiliation as the primary organization
Source
services-crm:modules/merges/tests/unit/services/planning/contact-collections.spec.js#shows the primary organization for review as a defaulted, optional decision when two participants hold one at different organizations
09 Linked details preserve their usable sourceruleunittest
Proves
BR-CAP-CRM-DQ-014-09
Preconditions
Prepare identical organization-source links, an unresolved link and a link losing its affiliation.
Steps
Compute the plan.
Expected
Identical sources collapse, unresolved details are dropped as replaced and the detached affiliation's detail becomes a described copy.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/unit/services/planning/linked-contact-information.spec.js#treats two items linked to the same record as one item, so the slot asks nothing
services-crm:modules/merges/tests/unit/services/planning/linked-contact-information.spec.js#lists a linked item that does not resolve and is replaced under linked_value_replaced
services-crm:modules/merges/tests/unit/services/planning/linked-contact-information.spec.js#turns a linked item whose affiliation the merged contact does not keep into a copy of its value
Source
services-crm:modules/merges/tests/unit/services/planning/linked-contact-information.spec.js#treats two items linked to the same record as one item, so the slot asks nothing
10 Computed presentation is outside merge choicesruleunittest
Proves
BR-CAP-CRM-DQ-014-10
Preconditions
Participants differ on sort names, automatic regions and record numbers.
Steps
Build the plan.
Expected
Name and number are not questions, and region is recalculated unless manually assigned.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/unit/services/planning/contact-fields.spec.js#offers no choice about the contact number, which stays the survivor’s
services-crm:modules/merges/tests/unit/services/planning/contact-fields.spec.js#recalculates the region rather than choosing between two, and says so
services-crm:modules/merges/tests/unit/services/planning/contact-fields.spec.js#keeps a region a participant set by hand, because an overridden region is not recalculated
Source
services-crm:modules/merges/tests/unit/services/planning/contact-fields.spec.js#offers no choice about the computed sort name
11 Archived custom values receive no merge writeedgeapitest
Proves
BR-CAP-CRM-DQ-014-12
Preconditions
Both participants hold an archived custom field.
Steps
Prepare the preview and run its combination.
Expected
No choice appears for that field and execution succeeds without updating it.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/merges/tests/e2e/merges.e2e.spec.js#offers no conflict about the archived field
12 Custom validation applies only to changed valuesfailureapinegativetest
Proves
BR-CAP-CRM-DQ-014-13
Preconditions
One survivor lacks a later-required value and another plan clears an existing required value.
Steps
Execute both plans.
Expected
The first succeeds; the second identifies the required field and leaves the survivor unchanged.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/merges/tests/integration/services/merges/merge-execution.integration.spec.js#merges, a field the merge changes nothing about not standing in its way
13 Discarded information retains a reason and sourceinvariantunittest
Proves
BR-CAP-CRM-DQ-014-14
Preconditions
Use a snapshot containing every difference type and the four-contact example.
Steps
Compute previews.
Expected
Each omitted value identifies its original records and responsible question, default or rule.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/unit/services/planning/merge-decisions.spec.js#names a conflict, a default or a rule for every value it drops, over a snapshot of every kind of difference
services-crm:modules/merges/tests/unit/services/planning/worked-example.spec.js#attributes every value the survivor will not hold to the conflict or the rule that dropped it
Source
services-crm:modules/merges/tests/unit/services/planning/merge-decisions.spec.js#names a conflict, a default or a rule for every value it drops, over a snapshot of every kind of difference
14 The wizard exposes automatic and exceptional outcomesinteractionbrowsertest
Proves
BR-CAP-CRM-DQ-014-01 BR-CAP-CRM-DQ-014-05 BR-CAP-CRM-DQ-014-06 BR-CAP-CRM-DQ-014-14
Preconditions
Prepare a sparse/full pair, four e-mails and deceased records with spouse connections.
Steps
Merge through the wizard and acknowledge omissions.
Expected
Automatic results are visible, chosen values remain, deceased status is answered and internal spouse links clear.
Data
The existing scenario setup supplies the required records.
Bound to
Source
react-console:acceptance/crm/playwright/journeys/merging/CRM-ACC-0254.spec.ts#CRM-ACC-0254
15 The chosen photo attaches to the retained contacttransitionapinegativeproposed
Proves
BR-CAP-CRM-DQ-014-11
Preconditions
Two participants with different managed photos and a fixed clock.
Steps
Choose the absorbed participant’s photo, execute and inspect both managed assets.
Expected
The chosen photo attaches to the survivor and the unused photo is detached with its thirty-day retirement deadline.
Data
Run-owned records and caller permissions that distinguish the two cases.
Source
services-crm:modules/merges/tests/unit/services/planning/merge-decisions.spec.js#says so when the survivor keeps its own photo and a participant’s is dropped
16 Contact details remain usable after organization and relationship changesinteractionapiproposed
Proves
BR-CAP-CRM-DQ-014-01 BR-CAP-CRM-DQ-014-02 BR-CAP-CRM-DQ-014-03 BR-CAP-CRM-DQ-014-04 BR-CAP-CRM-DQ-014-05 BR-CAP-CRM-DQ-014-06 BR-CAP-CRM-DQ-014-07 BR-CAP-CRM-DQ-014-08 BR-CAP-CRM-DQ-014-09 BR-CAP-CRM-DQ-014-10 BR-CAP-CRM-DQ-014-12 BR-CAP-CRM-DQ-014-13 BR-CAP-CRM-DQ-014-14 BR-CAP-CRM-DQ-014-11
Preconditions
Run-owned contact and organization records, the relevant staff permissions and the related state described by the sequence.
Steps
Choose contact detail slots and affiliations, merge the contacts, then merge their source organizations with a different retained slot. Read the surviving linked details and consent.
Expected
The linked values, affiliation ownership and consent remain consistent with the named rules.
Data
An isolated workspace with related records and fixed timestamps; owned participant failure injection where requested.
Source
CAP-CRM-DQ-014; CAP-CRM-DQ-015; CAP-CRM-DQ-017; CAP-CRM-ENT-005; CAP-CRM-ENT-009; WF-CRM-DQ-005; WF-CRM-DQ-006

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