Establish a person’s CRM record
Purpose
A coordinator needs a recognizable person record before recording membership work, communications, or organizational responsibilities against that person. This capability establishes that identity from entered information, keeps the person's owned details together, and gives later staff work a record to find rather than a loose name or e-mail address.
How It Works
Staff enter name components, optionally choose a contact type, and supply the other information appropriate to the person. Rhythm constructs display and sort names from those components and normalizes recognized honorifics and repeated nicknames. A first or last name anchors identification; entering only a computed full name does not substitute for the components.
The service validates the workspace's references and information, assigns a contact number, and writes the aggregate. Creation can retain an unused client identity. The retry-safe time-ordered identity path compares repeated creation requests with the original request so a network retry can recover the created person rather than creating a second one. Numbers are allocated separately and gaps can remain after a refused transaction.
Status describes the person independently of archive. A supplied spouse reference is reciprocal, so creation can also change the other person's record and version. Photos must be made permanent before the person write succeeds. Duplicate-block handling remains a boundary with Data Quality, including its separately authorized override.
Example
A membership coordinator enters Ruth Kim with a member contact type, work phone, two e-mail addresses, and a home address. Rhythm returns the derived name and assigned contact number with the saved collections. The coordinator opens the contact page to inspect them. If the create response is lost, an integration using the supported repeatable identity and identical request can recover the same record.
Ruth's coordinator also checks the refusal paths before relying on the identity. A request containing only credentials has not supplied the minimum person name, and an unknown Member type does not silently create an untyped person. She corrects the named problem and retries. A successful read then shows the name Rhythm derives, not a full-name string the caller independently calculates. If Ruth's primary e-mail conflicts, the duplicate override path does not release that uniqueness constraint. The coordinator must resolve the actual conflicting input rather than assume every refusal is a warning that can be confirmed.
Why It Works This Way
Our reading is that structured names preserve enough information to display and sort a person consistently; accepting a free-form computed name would make those views disagree. Minimum identification and field limits reject unusable input before it becomes a shared reference. Separate server numbers supply familiar identifiers without making them safe retry keys or gap-free counts.
The creation digest protects against interpreting a different request as an innocent retry. Workspace-scoped type and spouse checks keep the identity meaningful within the customer's records, and reciprocal spouse updates prevent one-sided claims. Photo preparation avoids storing a record whose selected image cannot be saved. Duplicate override authority prevents a mere confirmation from bypassing a stronger creation refusal; it does not replace primary-e-mail uniqueness.
Relationships
Maintain reliable contact points and Capture a person’s communication choices own the details saved with the person. Keep customer-defined information with records uses Platform metadata definitions for additional values. Locate people and organizations supplies subsequent discovery. Affiliations and Roles owns organization ties. Platform supplies files and security, while Data Quality owns duplicate policy and merge outcomes.