Skip to content

ATS-CRM-DQ-017Combine organizations and their connections safely: Capability Test Specification

Markdown

ATS-CRM-DQ-017

Combine organizations and their connections safely: Capability Test Specification

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-CRM-DQ-017

Design

Executed by
TST-CRM-DQ-181

KindAcceptance test setProduct areaCRMModuleDuplicate Review and Record MergingRevision1

Read atservices-crm a8d1364freact-console baf6dae3

Coverage

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

Test Scenarios

11 scenarios proving CAP-CRM-DQ-017; 7 bound to an existing test.

01 Hierarchy choices exclude cycle-producing parentsvalidationunittest
Proves
BR-CAP-CRM-DQ-017-01
Preconditions
Participants include an ancestor/descendant pair and possible outside parents.
Steps
Build their plan.
Expected
Forbidden parents are absent, removed internal links are explained and children move to the survivor.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/unit/services/planning/organization-hierarchy.spec.js#leaves the survivor with no parent, because the two become one organization
services-crm:modules/merges/tests/unit/services/planning/organization-hierarchy.spec.js#reports their reassignment to the survivor as a relationship action
Source
services-crm:modules/merges/tests/unit/services/planning/organization-hierarchy.spec.js#leaves the survivor with no parent, because the two become one organization
02 Organization domains retain distinct alternativesruleunittest
Proves
BR-CAP-CRM-DQ-017-02
Preconditions
Participants have different primary and alternate domains.
Steps
Plan with each primary choice.
Expected
The remaining domains form the alternate union and flags combine.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/unit/services/planning/organization-fields.spec.js#unions every other distinct domain into the alternate domain names
services-crm:modules/merges/tests/unit/services/planning/organization-fields.spec.js#moves the chosen domain into the alternates when staff choose the other one
services-crm:modules/merges/tests/unit/services/planning/organization-fields.spec.js#unions every participant’s flags rather than choosing between them
Source
services-crm:modules/merges/tests/unit/services/planning/organization-fields.spec.js#unions every other distinct domain into the alternate domain names
03 Different types require review without a blockeredgeunittest
Proves
BR-CAP-CRM-DQ-017-03
Preconditions
Participants have different organization types.
Steps
Compute their preview.
Expected
A type choice and warning appear without blocking the merge.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/unit/services/planning/organization-decisions.spec.js#asks which type the survivor keeps and warns that they may not be duplicates at all
Source
services-crm:modules/merges/tests/unit/services/planning/organization-decisions.spec.js#asks which type the survivor keeps and warns that they may not be duplicates at all
04 Affiliations move and overlapping stays combinetransitionapitest
Proves
BR-CAP-CRM-DQ-017-04
Preconditions
One employee belongs only to the absorbed organization and another belongs to both.
Steps
Execute.
Expected
No affiliation retains the absorbed organization and the equivalent stay combines into the survivor's affiliation.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/merges/tests/integration/services/merges/organization-merge-execution.integration.spec.js#leaves no affiliation naming the organization that went
05 Affiliation writes enforce the ceilingboundaryunitnegativetest
Proves
BR-CAP-CRM-DQ-017-05
Preconditions
Prepare 100,000-row and 100,001-row plans plus a combination exceeding the limit.
Steps
Build the previews.
Expected
The boundary plan is allowed and both excessive variants are blocked.
Data
The existing scenario setup supplies the required records.
Bound to
services-crm:modules/merges/tests/unit/services/planning/organization-decisions.spec.js#plans a merge that writes exactly 100,000 affiliation rows without a blocker
services-crm:modules/merges/tests/unit/services/planning/organization-decisions.spec.js#refuses a merge whose affiliation rows rewritten and combined away pass the ceiling, though it moves fewer
Source
services-crm:modules/merges/tests/unit/services/planning/organization-decisions.spec.js#refuses a merge of 100,001 affiliations
06 Employee links follow retained organization detailsinteractionapitest
Proves
BR-CAP-CRM-DQ-017-06
Preconditions
Prepare links to kept and discarded slots and to an affiliation that combines.
Steps
Execute the plan.
Expected
Kept links remain, discarded slots and combined affiliations redirect appropriately and every change is recorded.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/merges/tests/integration/services/merges/organization-merge-execution.integration.spec.js#re-points a link to a record that lost its slot to the record of its type the merge kept
07 Preferred-address selection survives executioninvariantapitest
Proves
BR-CAP-CRM-DQ-017-07
Preconditions
Two organizations prefer different address types.
Steps
Execute their chosen preview.
Expected
Only the address selected by the plan remains preferred.
Data
The existing scenario setup supplies the required records.
Bound to
Source
services-crm:modules/merges/tests/integration/services/merges/organization-merge-preferred-address.integration.spec.js#carries the merge out, rather than failing on the preferred-address index
08 Any added moved affiliation invalidates approvalconcurrencyunitproposed
Proves
BR-CAP-CRM-DQ-017-09
Preconditions
Approve an organization plan whose dependent affiliations are identified.
Steps
Add a colliding affiliation, then separately add a non-colliding affiliation.
Expected
Both additions change the material fingerprint and require renewed approval.
Data
The existing scenario setup supplies the required records.
Source
FND-CRM-DQ-026
09 Organization combination works across the full console journeyinteractionbrowserproposed
Proves
BR-CAP-CRM-DQ-017-01 BR-CAP-CRM-DQ-017-02 BR-CAP-CRM-DQ-017-04 BR-CAP-CRM-DQ-017-05 BR-CAP-CRM-DQ-017-06
Preconditions
Prepare children, employees, domains and linked details.
Steps
Merge, attempt an oversized plan and combine an ancestor with its descendant.
Expected
Domains, hierarchy, people and links follow their choices; excessive size is refused and large work warns.
Data
The existing scenario setup supplies the required records.
Source
FND-CRM-DQ-031
10 Organization execution refreshes computed statusruleapinegativeproposed
Proves
BR-CAP-CRM-DQ-017-08
Preconditions
Organizations whose combined roles and locations change compliance and automatic region inputs.
Steps
Inspect the preview choices, execute and read the survivor after recomputation.
Expected
No choice asks for a computed compliance or region value; the survivor reflects recomputation from the merged records.
Data
Run-owned records and caller permissions that distinguish the two cases.
Source
services-crm:modules/merges/tests/unit/services/planning/organization-fields.spec.js#never offers the contact role compliance status and recomputes it after the merge
11 Organization slot decisions preserve employee informationinteractionapiproposed
Proves
BR-CAP-CRM-DQ-017-01 BR-CAP-CRM-DQ-017-02 BR-CAP-CRM-DQ-017-03 BR-CAP-CRM-DQ-017-04 BR-CAP-CRM-DQ-017-05 BR-CAP-CRM-DQ-017-06 BR-CAP-CRM-DQ-017-07 BR-CAP-CRM-DQ-017-09 BR-CAP-CRM-DQ-017-08
Preconditions
Run-owned contact and organization records, the relevant staff permissions and the related state described by the sequence.
Steps
Merge parent-related organizations with overlapping employee affiliations and different address slots. Read each employee and the resulting hierarchy.
Expected
Employee links, merged stays and hierarchy obey the named rules while contact-owned information remains usable.
Data
An isolated workspace with related records and fixed timestamps; owned participant failure injection where requested.
Source
CAP-CRM-DQ-017; CAP-CRM-DQ-014; CAP-CRM-ENT-002; CAP-CRM-ENT-006; 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.