ATS-CRM-DQ-019 Inspect merge outcomes and attribution: Capability Test Specification
Markdown Design / CRM / Duplicate Review and Record Merging / Follow Absorbed Identities and Outcomes / Capability Test Specification Inspect merge outcomes and attribution: 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.
Complete a merge, read it through the survivor and an alias, inspect record history as a reader and compare the recent-merge overview.
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-070 Validation gap: FND-CRM-DQ-070 Permission covered Edge gap: FND-CRM-DQ-070 Failure gap: FND-CRM-DQ-070 Boundary covered Concurrency gap: FND-CRM-DQ-070 Invariant covered Interaction covered Test Scenarios 10 scenarios proving CAP-CRM-DQ-019 ; 8 bound to an existing test.
02 Absorbed and surviving identities share lineage rule api test
Proves BR-CAP-CRM-DQ-019-02 Preconditions A merge has succeeded. Steps Request history through survivor and absorbed identity. Expected Both return the survivor's same history. Data The existing scenario setup supplies the required records. Bound to Source services-crm:modules/merges/tests/e2e/merges.e2e.spec.js #answers the merge in the survivor’s history 03 Historical identity remains readable after absorption rule api test
Proves BR-CAP-CRM-DQ-019-03 Preconditions Prepare deleted participants and visible or unavailable requesters. Steps List their merges. Expected Participant names come from originals and requester names are current or blank. Data The existing scenario setup supplies the required records. Bound to Source services-crm:modules/merges/tests/e2e/merges.e2e.spec.js #names the survivor and the records it took away, so a history list needs no further read 06 Record readers receive appropriately restricted lineage permission api negative test
Proves BR-CAP-CRM-DQ-019-07 BR-CAP-CRM-DQ-019-08 Preconditions Prepare a contact reader without merge management and an organization-only reader. Steps Read a contact's history and one outcome. Expected The contact reader sees history and field outcomes without login actions, carried decisions or checks; the other reader is denied. Data The existing scenario setup supplies the required records. Bound to Source services-crm:modules/merges/tests/e2e/merged-from-history.e2e.spec.js #answers the reader the survivor’s merged-from history, naming the merge and the record it absorbed 07 Console history connects summaries and outcomes permission browser test
Proves BR-CAP-CRM-DQ-019-09 Preconditions Prepare several completed merges. Steps Filter Recently Merged, open details and follow a record history entry. Expected Attribution and participants accompany retained, moved and discarded values, and history links open their merge. Data The existing scenario setup supplies the required records. Bound to Source react-console:acceptance/crm/playwright/journeys/merging/CRM-ACC-0266.spec.ts #CRM-ACC-0266 08 An application cannot erase the only retained original invariant api test
Proves INV-DOM-CRM-DQ-004-10 Preconditions A completed merge with absorbed originals and the ordinary application role. Steps Attempt to delete the merge row. Expected The row remains and the operation is refused. Data Records, versions and caller contexts owned by the run; transaction failure injection when the invariant concerns rollback. Bound to Source services-crm:modules/merges/tests/integration/db/record-merges.table.integration.spec.js #may not erase a merge, which holds the only copy left of the records it deleted 09 Privacy removal preserves a minimal attributed outcome rule api negative proposed
Proves BR-CAP-CRM-DQ-019-06 Preconditions A completed merge with personal values in originals and discarded outcomes, plus an authorized privacy request. Steps Remove the requested person’s original values, then inspect history and retained non-personal merge metadata. Expected Requested personal values are unavailable while minimal attribution remains. This proposed obligation is not implemented by the pinned suites. Data Run-owned records and caller permissions that distinguish the two cases. Source FND-CRM-DQ-010 ← Previous Capability Test Specification ATS-CRM-DQ-018 · Resolve identities absorbed by a merge: Capability Test Specification