--- id: JNY-CRM-ENT-001 title: Create a member record and inspect the saved information product_area: crm module: entities revision: 1 status: approved product_intent: proposed implementation_evidence: partially-observed source_sha: react-console: da63075876b2c5f4a6af07d457bb24ea8bf4c0c7 services-crm: 7ea48a414c42eade10d60753b8bcc323b1dd726f actor: ACT-CRM-001 goal: >- Enter a member’s information once, then inspect the saved record and its changes across the console and API. capabilities: - CAP-CRM-ENT-001 - CAP-CRM-ENT-003 - CAP-CRM-ENT-004 - CAP-CRM-ENT-005 - CAP-CRM-ENT-007 - CAP-CRM-ENT-008 - CAP-CRM-ENT-016 - CAP-CRM-ENT-018 screens: - '/console/{tenantId}/crm/contacts/new' - '/console/{tenantId}/crm/contacts/{id}' - '/console/{tenantId}/crm/contacts/{id}/edit' steps: - 'n': 1 surface: '/console/{tenantId}/crm/contacts/new' action: Start New Contact and select the member type. capability: CAP-CRM-ENT-018 expected: >- The active type choices are available, and selection opens the corresponding form. provenance: test source: >- react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0001.spec.ts#CRM-ACC-0001 - 'n': 2 surface: '/console/{tenantId}/crm/contacts/new' action: >- Enter identity, status, dates, three e-mails, two phones, two addresses, restrictions and two custom values, then create the contact. capability: CAP-CRM-ENT-001 expected: One contact is created and its record page opens. provenance: test source: >- react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0001.spec.ts#CRM-ACC-0001 - 'n': 3 surface: '/console/{tenantId}/crm/contacts/{id}' action: Inspect the Contact 360 cards. capability: CAP-CRM-ENT-003 expected: >- The tested name, type and contact-detail values appear; the test separately records that the communication-preferences card is hidden. provenance: test source: >- react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0001.spec.ts#CRM-ACC-0001 - 'n': 4 surface: getContact action: Retrieve the saved contact through the API. capability: CAP-CRM-ENT-005 expected: >- The entered values are stored once with normalized e-mails and phones, typed custom values, computed names and a server-assigned number. provenance: test source: >- react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0001.spec.ts#CRM-ACC-0001 - 'n': 5 surface: '/console/{tenantId}/crm/contacts/{id}/edit' action: 'Change two fields, inspect Review Changes and save.' capability: CAP-CRM-ENT-004 expected: 'The review identifies both edits, and one patch advances the version once.' provenance: test source: >- react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0006.spec.ts#CRM-ACC-0006 - 'n': 6 surface: listContactHistory action: Inspect Version History. capability: CAP-CRM-ENT-016 expected: >- Create and edit each have a revision attributed to the staff member and console. provenance: test source: >- react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0043.spec.ts#CRM-ACC-0043 alternates: - from_step: 1 condition: Only one active contact type exists. path: That type is already selected. outcome: Staff proceed directly to its form. provenance: test source: >- react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0033.spec.ts#CRM-ACC-0033 failures: - from_step: 2 condition: The entered primary e-mail matches a blocking duplicate rule. path: >- Creation returns a possible-duplicate refusal, with no confirmation control in the tested console path. outcome: The attempted contact is not created. provenance: test source: >- react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0042.spec.ts#CRM-ACC-0042 - from_step: 5 condition: Another staff member saves before this editor does. path: The save opens a conflict notice offering Reload. outcome: The earlier changes remain intact. provenance: test source: >- react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0009.spec.ts#CRM-ACC-0009 rules_in_play: - BR-CAP-CRM-ENT-001-01 - BR-CAP-CRM-ENT-001-02 - BR-CAP-CRM-ENT-001-04 - BR-CAP-CRM-ENT-001-07 - BR-CAP-CRM-ENT-005-01 - BR-CAP-CRM-ENT-005-03 - BR-CAP-CRM-ENT-005-04 - BR-CAP-CRM-ENT-007-01 - BR-CAP-CRM-ENT-008-03 - BR-CAP-CRM-ENT-004-01 - BR-CAP-CRM-ENT-004-11 - BR-CAP-CRM-ENT-016-01 - BR-CAP-CRM-ENT-003-06 assertions: - id: AS-JNY-CRM-ENT-001-01 statement: >- Creation leaves one member contact that appears once in a last-name search. provenance: test source: >- react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0001.spec.ts#CRM-ACC-0001 - id: AS-JNY-CRM-ENT-001-02 statement: >- The tested record cards match API values; communication preferences are verified through the API because their card is hidden. provenance: test source: >- react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0001.spec.ts#CRM-ACC-0001 - id: AS-JNY-CRM-ENT-001-03 statement: >- The create request does not choose the contact number; the server assigns it. provenance: test source: >- react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0001.spec.ts#CRM-ACC-0001 - id: AS-JNY-CRM-ENT-001-04 statement: >- History contains one revision for each committed change with staff attribution. provenance: test source: >- react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0043.spec.ts#CRM-ACC-0043 e2e_policy: required e2e_reason: >- Browser proof is required to exercise the chooser, form and record cards together; API checks verify the saved values. feature: FEAT-CRM-ENT-01 evidence: - >- `react-console` at `da63075876b2c5f4a6af07d457bb24ea8bf4c0c7`: examined `acceptance/crm/journeys/contacts/CRM-ACC-0001.json`, `CRM-ACC-0006.json`, `CRM-ACC-0043.json` and their Playwright specs under `acceptance/crm/playwright/journeys/contacts/`. - >- `services-crm` at `7ea48a414c42eade10d60753b8bcc323b1dd726f`: examined the capabilities' sources. approved_by: Andrew approved_at: 2026-10-22 narrative: status: needs-revision review: NARRATIVE-REVIEW-2026-10-23 narrative_sources: - section: What Can Go Differently provenance: unknown source: FND-CRM-ENT-081 note: The sole-type branch is observed in the component, but the formal alternate cites a browser scenario that does not assert it. - section: What Can Go Differently provenance: observed source: react-console:components/records/create/create-record-screen.tsx:CreateRecordScreen; react-console:lib/records/record-type-choice.ts:createStepFor - section: Story provenance: test source: >- react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0001.spec.ts#CRM-ACC-0001; react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0006.spec.ts#CRM-ACC-0006; react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0043.spec.ts#CRM-ACC-0043; react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0042.spec.ts#CRM-ACC-0042; react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0009.spec.ts#CRM-ACC-0009 - section: What Can Go Differently provenance: test source: >- react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0033.spec.ts#CRM-ACC-0033; react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0042.spec.ts#CRM-ACC-0042; react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0009.spec.ts#CRM-ACC-0009 - section: What Is True Afterwards provenance: test source: >- react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0001.spec.ts#CRM-ACC-0001; react-console:acceptance/crm/playwright/journeys/contacts/CRM-ACC-0043.spec.ts#CRM-ACC-0043 proved_by: [] --- # Create a member record and inspect the saved information ## Story A CRM Editor receives a new member's information and starts a contact record. She selects the member type and enters name components, status, dates, contact points, communication restrictions, and the association's custom values. Creation opens the saved record, where she checks the visible contact cards against what she entered. The process continues beyond a successful form submission. A service read confirms the stored normalized details, typed custom values, derived names, and assigned contact number. The existing browser specification records that the communication-preferences card is hidden, so those preferences are inspected through the service rather than assumed visible on the page. The coordinator later changes selected fields, reviews the proposed corrections, and saves against the read version. Finally she inspects history to connect creation and correction with attributed revisions. This joins staff entry, persistence, presentation, and change explanation while keeping their proof boundaries distinct. The coordinator treats this as a record-establishment task rather than proof of membership rights. For Ruth Kim, the member classification supplies CRM context; any membership entitlement belongs to its own application. She checks the saved person and the tested cards before later work relies on the identity. A visible contact page and an API read answer complementary questions, especially where the communication-preferences card is hidden. ## What Can Go Differently A duplicate-block refusal can stop creation before a person is saved; the tested console path does not provide a general confirmation bypass. If another editor saves first during correction, the coordinator receives a conflict and reloads before reapplying the intended changes against current information. When only one active contact type exists, the pinned creation component selects it in the chooser; the coordinator still uses Continue to open its form. For Ruth's association, a single Member choice therefore removes the need to choose among types while keeping that confirmation step. Having no active types is a different starting condition: the cited browser scenario explicitly checks entry to a form without a type chooser. It is not established that the browser scenario cited for the sole-type alternate proves preselection and Continue: it checks two active choices and no active choices instead. The alternate-proof finding records that missing assertion and binding. The formal alternate still says staff proceed directly to the form and labels its source as a test. That claim remains unresolved; the observed chooser sequence explains the experience but cannot be treated as proof of the formal alternate. ## What Is True Afterwards The association has one saved member contact whose tested visible values agree with the service read. The person has a server-assigned number and can be found by name. Stored communication choices remain verifiable even where their card is hidden. Creation and each committed correction contribute attributed revisions, giving later staff a way to investigate changes without treating an unchanged save as another edit.