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.
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.
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.
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. It is not established that the browser scenario cited for this alternate proves that sequence: it checks two active choices and no active choices instead. The alternate-proof finding records the missing assertion and incorrect binding. Component observation explains the staff experience, but it does not repair the formal test claim.
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.