Rhythm 2.0 Specifications

Appearance

ATS-CRM-ENT-001Establish a person’s CRM record

Markdown

ATS-CRM-ENT-001

Establish a person’s CRM record

Markdown
  • DocumentProposed

Planning

Proves capability
CAP-CRM-ENT-001

Design

Executed by
TST-CRM-ENT-774, TST-CRM-ENT-786, TST-CRM-ENT-787

KindAcceptance test setProduct areaCRMModuleEntitiesRevision1

Read atservices-crm a8d1364freact-console baf6dae3

Establish a person’s CRM record ​

Coverage ​

The category map separates specified cases from recorded gaps. A proposed case describes proof to implement; a binding identifies the assertions supplied by an existing executable file. The permission and transition ledgers record the individual checks needed for the capability.

Required ruleScenario or finding
BR-CAP-CRM-ENT-001-01ATS-CRM-ENT-001-01, ATS-CRM-ENT-001-20, ATS-CRM-ENT-001-21
BR-CAP-CRM-ENT-001-02ATS-CRM-ENT-001-02, ATS-CRM-ENT-001-18, ATS-CRM-ENT-001-19
BR-CAP-CRM-ENT-001-03ATS-CRM-ENT-001-03
BR-CAP-CRM-ENT-001-04ATS-CRM-ENT-001-04
BR-CAP-CRM-ENT-001-05ATS-CRM-ENT-001-05
BR-CAP-CRM-ENT-001-06ATS-CRM-ENT-001-06
BR-CAP-CRM-ENT-001-07ATS-CRM-ENT-001-07
BR-CAP-CRM-ENT-001-08ATS-CRM-ENT-001-08, ATS-CRM-ENT-001-17
BR-CAP-CRM-ENT-001-09ATS-CRM-ENT-001-09, ATS-CRM-ENT-001-22
BR-CAP-CRM-ENT-001-10ATS-CRM-ENT-001-10, ATS-CRM-ENT-001-16
BR-CAP-CRM-ENT-001-11ATS-CRM-ENT-001-11
BR-CAP-CRM-ENT-001-12ATS-CRM-ENT-001-12, ATS-CRM-ENT-001-14
BR-CAP-CRM-ENT-001-13ATS-CRM-ENT-001-13

The interaction scenarios exercise locate people and organizations; save corrections without overwriting another change; maintain reliable contact points; organize the workspace’s record classifications. They change one part of a prepared record and inspect the dependent outcome. Unbound interactions remain proposed rather than implying an existing end-to-end implementation.

Source Evidence ​

The frontmatter pins the repositories and identifies the source anchors for each scenario. Bindings record inspected assertions, while unbound cases remain proposed. Source inspection supplies no execution result or product approval.

Coverage

  • Rule covered
  • Transition covered
  • Validation covered
  • Permission covered
  • Edge covered
  • Failure covered
  • Boundary covered
  • Concurrency covered
  • Invariant covered
  • Interaction covered

Test Scenarios

23 scenarios proving CAP-CRM-ENT-001; 14 bound to an existing test.

01 a contact needs a first or a last namevalidationapinegativetest
Proves
BR-CAP-CRM-ENT-001-01 INV-DOM-CRM-ENT-001-01
Preconditions
Prepare a workspace and a caller with crm.contacts.create.
Steps
POST a contact with blank first and last names.
Expected
400 naming first_name; no contact written.
Data
No additional fixtures.
Bound to
Source
services-crm:modules/entities/tests/e2e/contacts-names.e2e.spec.js#answers 400 for a contact with neither a first nor a last name, naming the rule
02 the computed names are built from the partsruleapitest
Proves
BR-CAP-CRM-ENT-001-02 INV-DOM-CRM-ENT-001-02
Preconditions
No additional setup is required.
Steps
POST a contact with every name part.
Expected
Name, full_name and name_last_first as the rule builds them.
Data
Use a contact with all seven name parts.
Bound to
Source
services-crm:modules/entities/tests/e2e/contacts-names.e2e.spec.js#builds the full name from every part in order, trimmed and singly spaced
03 a computed name cannot be sent and is never parsedvalidationapinegativetest
Proves
BR-CAP-CRM-ENT-001-03
Preconditions
No additional setup is required.
Steps
POST a contact with full_name and no parts; POST one with a name beside parts.
Expected
400 each time; no parts derived.
Data
No additional fixtures.
Bound to
Source
services-crm:modules/entities/tests/e2e/contacts-names.e2e.spec.js#answers 400 for a full name sent instead of name parts, and never splits it into parts
04 Names are tidied and the tidying is displayed before savingrulebrowsertest
Proves
BR-CAP-CRM-ENT-001-04
Preconditions
No additional setup is required.
Steps
Save salutation "mr", prefix "dr" and nickname equal to the first name.
Expected
Prefix "Mr."/"Dr.", no salutation, no nickname; the console review lists both changes.
Data
No additional fixtures.
Bound to
Source
services-crm:modules/entities/tests/integration/services/persistence/contacts.integration.spec.js#moves an honorific salutation to the prefix, start-cased and dotted (RB-2367)
05 Field limits refuse overlong values naming each fieldboundarybrowsernegativetest
Proves
BR-CAP-CRM-ENT-001-05
Preconditions
No additional setup is required.
Steps
Create and update with a 201-character first name, 10,001-character notes and a 255-character e-mail.
Expected
400 naming each field; 200 and 10,000 accepted.
Data
No additional fixtures.
Bound to
Source
services-crm:modules/entities/tests/integration/services/persistence/contacts.field-rules.integration.spec.js#names every overlong name part of one request at once
06 Client ids are preserved, minted ids are UUIDv7, taken ids are rejectedboundaryapinegativetest
Proves
BR-CAP-CRM-ENT-001-06
Preconditions
No additional setup is required.
Steps
Create without an id, with a free id and with a taken id.
Expected
UUIDv7; the named id; 400.
Data
No additional fixtures.
Bound to
Source
services-crm:modules/entities/tests/e2e/contacts.e2e.spec.js#keeps the id the body named, which is no UUIDv7
07 Numbers are the server's, per workspace, with gaps and collision recoveryinvariantapitest
Proves
BR-CAP-CRM-ENT-001-07 INV-DOM-CRM-ENT-001-03
Preconditions
Prepare a seed that hands out a number another row holds.
Steps
Create contacts, one rolled back.
Expected
Consecutive numbers per workspace; a rolled-back create leaves a gap; a taken number becomes the highest plus one.
Data
Use seeded number_seeds.
Bound to
Source
services-crm:modules/entities/tests/integration/services/persistence/contacts.integration.spec.js#saves the contact under the highest number plus one, 4001
08 a retried create returns the first contactedgeapinegativetest
Proves
BR-CAP-CRM-ENT-001-08
Preconditions
Prepare a create that committed.
Steps
Repeat it with the same id and body; then with the same id from another request.
Expected
The same contact, no second one; 409 for the other request.
Data
No additional fixtures.
Bound to
Source
services-crm:modules/entities/tests/integration/services/contacts/contact-create.integration.spec.js#answers the retry with the contact the first attempt made
09 the type is optional and must be the workspace’svalidationapinegativetest
Proves
BR-CAP-CRM-ENT-001-09 INV-DOM-CRM-ENT-001-14
Preconditions
Prepare a workspace with one contact type.
Steps
Create with that type, with none and with an unknown one.
Expected
Saved; saved with no type; 409 and nothing saved.
Data
No additional fixtures.
Bound to
Source
services-crm:modules/entities/tests/e2e/contacts.e2e.spec.js#answers 409 for a type the tenant does not have, and saves no contact
10 Status is a closed listvalidationapinegativetest
Proves
BR-CAP-CRM-ENT-001-10 INV-DOM-CRM-ENT-001-04
Preconditions
No additional setup is required.
Steps
Write a contact with status "archived".
Expected
Rejected by contacts_status_check.
Data
No additional fixtures.
Bound to
Source
services-crm:modules/entities/tests/integration/db/contacts.table.integration.spec.js#refuses a status outside the closed list by contacts_status_check
11 Spouse links are reciprocal and guardedinvariantapinegativetest
Proves
BR-CAP-CRM-ENT-001-11 INV-DOM-CRM-ENT-001-09
Preconditions
Three contacts exist; two are already a spouse pair. A separate pair is available for a valid link.
Steps
Create a reciprocal link in the free pair; try to claim a member of the existing pair; clear one side of the free pair; link it again and delete one spouse.
Expected
The free pair links in both directions. The occupied spouse is refused without changing either pair. Clearing or deleting a spouse clears the surviving reference.
Data
No additional fixtures.
Bound to
Source
services-crm:modules/entities/tests/integration/services/persistence/contacts.spouse.integration.spec.js#links the other spouse back when a contact is created naming it
12 Duplicate confirmation needs authorized overridepermissionbrowsernegativetest
Proves
BR-CAP-CRM-ENT-001-12
Preconditions
Prepare a workspace whose e-mail match rule is set to block.
Steps
Attempt the blocked create as a non-holder with confirmation and a reason, then as an override holder with both.
Expected
The non-holder receives 409, and the override holder creates the contact.
Data
Use seeded duplicate rules.
Bound to
Source
react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0042.spec.ts#CRM-ACC-0042
13 a photo that cannot be saved rejects the createfailureapinegativetest
Proves
BR-CAP-CRM-ENT-001-13
Preconditions
No additional setup is required.
Steps
POST a contact naming a staged upload that is not there.
Expected
400 naming image_url and no contact.
Data
No additional fixtures.
Bound to
Source
services-crm:modules/entities/tests/e2e/contacts.e2e.spec.js#answers 400 for a photo whose upload is not there, naming the field that failed
14 an override holder creates a blocked contact with a reason, and the override is recordedpermissionapiproposed
Proves
BR-CAP-CRM-ENT-001-12
Preconditions
Prepare a caller holding crm.contacts.create-despite-duplicate-block; a blocking rule.
Steps
Create the blocked contact with duplicate_override_reason, then without a reason.
Expected
Created and an override row recorded; rejected without a reason.
Data
Use seeded duplicate rules.
Source
services-crm:modules/entities/services/contacts/contact-create.ts:createRequestedContact
15 the journey: a complete member recorded once and read the same everywhereinteractionbrowsertest
Proves
AS-JNY-CRM-ENT-001-01 AS-JNY-CRM-ENT-001-02 AS-JNY-CRM-ENT-001-03 AS-JNY-CRM-ENT-001-04
Preconditions
Prepare a member contact type and two custom fields; a standard user.
Steps
Run JNY-CRM-ENT-001.
Expected
One contact; the 360 and the API agree; the number is the server's; one revision per save.
Data
Use seeded types and custom fields.
Bound to
Source
react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0001.spec.ts#CRM-ACC-0001
16 Create each supported contact statustransitionapiproposed
Proves
BR-CAP-CRM-ENT-001-10
Preconditions
Four valid person requests have distinct primary addresses.
Steps
Create one contact with each supported status and read every saved record.
Expected
Each saved status matches its request; the default-status request reads active.
Data
Run-owned records and configuration in an isolated workspace.
Source
services-crm:modules/entities/tests/integration/db/contacts.table.integration.spec.js#refuses a status outside the closed list by contacts_status_check
17 Race identical create retriesconcurrencyapiproposed
Proves
BR-CAP-CRM-ENT-001-08
Preconditions
Two clients share one unused lowercase time-ordered identity and identical person input.
Steps
Release both create requests together; read the identity and count records with that identity.
Expected
Both requests identify the same saved person and exactly one contact is present.
Data
Run-owned records and configuration in an isolated workspace.
Source
services-crm:modules/entities/tests/integration/services/contacts/contact-create.integration.spec.js#answers the retry with the contact the first attempt made
18 Find the newly established personinteractionapiproposed
Proves
BR-CAP-CRM-ENT-001-02 BR-CAP-CRM-ENT-003-06
Preconditions
A person request uses a distinctive last name.
Steps
Create the person, search by that name and open the saved record.
Expected
Search identifies the saved person and the opened record carries the saved identity.
Data
Run-owned records and configuration in an isolated workspace.
Source
services-crm:modules/entities/tests/e2e/contacts-names.e2e.spec.js#builds the full name from every part in order, trimmed and singly spaced; services-crm:modules/entities/tests/e2e/contacts.e2e.spec.js#answers only the fields `?fields=` named, with the id
19 Correct a newly established personinteractionapiproposed
Proves
BR-CAP-CRM-ENT-001-02 BR-CAP-CRM-ENT-004-01
Preconditions
A person has just been created.
Steps
Read its version and correct its name parts through a version-tested save.
Expected
The corrected record retains its identity and shows the newly derived names.
Data
Run-owned records and configuration in an isolated workspace.
Source
services-crm:modules/entities/tests/e2e/contacts-names.e2e.spec.js#builds the full name from every part in order, trimmed and singly spaced; services-crm:modules/entities/tests/e2e/contacts.e2e.spec.js#answers 400 naming sys_version to a patch that tests no version
20 Create a person with usable contact pointsinteractionapiproposed
Proves
BR-CAP-CRM-ENT-001-01 BR-CAP-CRM-ENT-005-01
Preconditions
A valid name and three distinct email values are prepared.
Steps
Create the person with all three addresses and read the ordered collection.
Expected
The contact is created once and the saved contact points retain their declared order.
Data
Run-owned records and configuration in an isolated workspace.
Source
services-crm:modules/entities/tests/e2e/contacts-names.e2e.spec.js#answers 400 for a contact with neither a first nor a last name, naming the rule; services-crm:modules/entities/tests/integration/services/persistence/contacts.integration.spec.js#refuses a fourth e-mail address
21 Create with a required customer valueinteractionapiproposed
Proves
BR-CAP-CRM-ENT-001-01 BR-CAP-CRM-ENT-008-04
Preconditions
An active contact definition requires a value during creation.
Steps
Create without that value, then create with a valid value and read the resulting person.
Expected
The first attempt creates no person; the corrected attempt stores the person and its custom value together.
Data
Run-owned records and configuration in an isolated workspace.
Source
services-crm:modules/entities/tests/e2e/contacts-names.e2e.spec.js#answers 400 for a contact with neither a first nor a last name, naming the rule; services-crm:modules/entities/tests/e2e/contacts-custom-fields.e2e.spec.js#saves a replace of a contact created before the field was required, leaving the field out
22 Keep the classification chosen before deactivationinteractionapiproposed
Proves
BR-CAP-CRM-ENT-001-09 BR-CAP-CRM-ENT-018-08
Preconditions
A coordinator has selected an active person classification.
Steps
Deactivate the classification before creation completes; save the person and reopen the chooser.
Expected
The saved person retains that classification while a new selection excludes the inactive choice.
Data
Run-owned records and configuration in an isolated workspace.
Source
services-crm:modules/entities/tests/e2e/contacts.e2e.spec.js#answers 409 for a type the tenant does not have, and saves no contact; react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0033.spec.ts#CRM-ACC-0033
23 Exercise every declared authority independentlypermissionapinegativeproposed
Proves
BR-CAP-CRM-ENT-003-07 BR-CAP-CRM-ENT-003-09
Preconditions
An eligible record and configuration fixture exist for each operation; the caller can reach only the run’s workspace.
Steps
For each declared permission, execute its matching operation with that permission, then without it while retaining the other required grants. Read affected records after every refused mutation.
Expected
The authorized case reaches the operation; the missing-grant case is refused and preserves saved data. Record access alone does not authorize the other declared actions.
Data
Run-owned records and configuration in an isolated workspace.
Source
services-crm:aws/crm.service.ts:ApplicationPermissions; services-crm:modules/entities/aws/api/entities.routes.ts

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