Contact Records
Overview
Contact Records gives association staff a continuing identity for each person they know. Names, contact points, organizational connections, and customer-defined information belong to that identity, so staff can recognize the same person across different kinds of work.
A contact is useful beyond the moment of creation. Staff can find it again, inspect its saved information, and use it as the person named by other applications. The feature supports both a coordinator entering a member and an integration creating records through the service.
Why It Exists
Our reading is that staff need one continuing person identity because a member's circumstances change more often than their identity does. Ruth can change employer, replace her work phone and acquire a different classification while association work still concerns the same person. If staff create another contact for each change, they must guess which record carries the usable information and which organizational ties explain the member's past.
Contact creation supplies that shared starting point; discovery brings staff back to it, and customer-defined values let the association retain information that the common identity model does not name. These are related needs, but they remain separate operations. A saved identity does not by itself establish membership entitlement, grant application access or prove that a search projection has caught up with the latest change.
Who Uses It
The CRM Editor establishes and maintains a person's record, while the CRM Reader finds people and inspects information within granted access. The Data Importer brings external information through authorized record operations. The CRM Administrator handles classifications and exceptional creation authority; the CRM System supplies derived information and related updates.
How It Works
A staff member chooses a contact type where appropriate, enters name components and other information, and creates the record. Rhythm derives the names used for display and sorting, assigns a workspace contact number, validates the supplied references, and stores the person and owned information together. The contact page and a service read expose the resulting record.
Later discovery can use paged lists, name search, or current affiliations to an organization and its descendants. Quick Search is a separate projection updated from committed changes, so its timing differs from a direct record read. Customer-defined values remain attached to the contact but use definitions supplied by Platform metadata.
Creation begins with identifying the person, rather than with typing a single display label. The coordinator enters Ruth's first and last names and, where useful, a prefix, nickname or credentials. Review Changes makes supported normalization visible before the console submits the request. A contact can be untyped; selecting Member gives the record a classification, rather than granting membership benefits. A supplied classification must exist in this workspace. A reference failure stops creation instead of leaving a person whose classification cannot be explained.
Duplicate handling is another decision before success. A blocked creation cannot proceed merely because the coordinator confirms a warning. The exceptional path requires the dedicated override authority and a reason. That Data Quality boundary is separate from the primary-e-mail constraint, which the contact-point capability enforces. After validation, the saved contact has a durable identity and a separately allocated number. Integrations can recover a repeated creation through the supported identical-request retry path; the number is not a retry token or a count of successfully created people.
Opening the saved record is the next meaningful step. A direct read exposes its owned information and derived names; a limited service projection returns selected information with the identity. List discovery searches names rather than every visible field. Filtering for a chapter considers current secondary connections as well as the primary one. Quick Search follows a committed-change projection, so an immediate direct read and a later search result need separate inspection. Finding the contact does not authorize every related operation: application access, workspace reach and operation permissions still apply.
Examples
A professional association records Ruth Kim as a member, with work and home contact points and a customer-defined specialization. After saving, a coordinator opens Ruth's contact page to inspect the information and searches for her again by name. A chapter coordinator can also find Ruth through a currently effective secondary chapter affiliation even when her primary organization is her employer.
Ruth's association records a specialization through an existing contact custom-field definition. If the coordinator sends an undeclared specialization key or an invalid option, the save refuses the field instead of inventing a new definition. She corrects the input, saves, and reads back the declared value. When an integration later submits another named custom key, Ruth's specialization remains because custom values have their own merge semantics.
A week later Ruth reports a corrected work phone. The coordinator edits the existing contact rather than creates another Ruth, reviews the correction, and saves against the version she read. She opens the record again to check the phone and the unchanged specialization. She then searches by Ruth's name; searching the ordinary name-list operation for the phone or contact number is not equivalent. If Quick Search still shows the older label immediately after saving, the direct read establishes what was persisted while search freshness remains a separate question.
Decisions and Tradeoffs
Our reading is that a continuing person identity separates changes in circumstances from changes in who the person is. A simpler collection of names in each application would leave staff reconciling conflicting phone numbers and employers. Derived names make display and sorting consistent, but require callers to supply structured name parts rather than an arbitrary computed label.
Custom values give an association flexibility within declared definitions. That flexibility has a boundary: it does not make every related record extensible or permit undeclared fields. Likewise, discovery offers several questions with different answers. A primary-organization search subtitle helps recognition; it does not replace current-affiliate membership. Event-fed search keeps a save separate from the search reaction, at the cost of requiring readers and tests to distinguish durable persistence from projection freshness.
Scope and Boundaries
This feature owns person creation, record discovery, and persistence of customer-defined values. Contact Details and Communication Preferences explains how contact points behave; Affiliations and Roles explains organizational connections. Platform owns custom field definitions, layouts, query execution, and search infrastructure. Data Quality owns duplicate decisions and merging, although creation must respect its refusal boundary.
Outcomes
Staff have a shared person record that they can retrieve and use for later association work. The Contact Records acceptance suite examines creation, reading, discovery, and custom information together. Its specifications and executable bindings describe intended proof; their existence alone does not establish that all acceptance tests pass at the pinned milestone.
Its Capabilities
Establish a person’s CRM record turns entered information into a recognizable person with derived names and a durable identity. Locate people and organizations provides authorized discovery and reads for staff and integrations. Keep customer-defined information with records preserves customer values alongside their owning contact or organization. Create a member record and inspect the saved information and Find current affiliates across an organization hierarchy show these capabilities in staff workflows.