Keep customer-defined information with records
Purpose
Associations need to keep information that is specific to their work, such as professional specialization or an internal reference, beside the shared contact or organization identity. This capability persists those values using Platform's declared definitions, so CRM can support customer information without treating every customer-defined business term as a built-in record property.
How It Works
A save names custom values in a map. Named keys are merged into existing values; omitted keys and an empty map preserve them. A null or blank value clears an individual key, while removing the entire map is not a supported clearing command. Reads return the readable values together in that map rather than as competing top-level properties.
Each writable key must match an active workspace definition for the record kind. Rhythm converts supported input to its declared type or refuses the field, including reference ownership, list options, numeric precision, and date-time form. Required values constrain creation and clearing without making an older record unsaveable merely because a definition later becomes required. Rich-text values use sanitized editing and rendering. Affiliations, roles, and affiliation types do not gain custom values through this capability.
Example
An association defines a specialization field for contacts in Platform metadata. A coordinator saves Ruth's specialization and later changes only that named key while correcting her phone. Other stored custom values remain. Clearing the specialization explicitly differs from submitting an empty custom-value map, which leaves it alone; an unknown field name refuses the save rather than creating an undeclared field.
The association names its specialization field Professional Discipline and gives it declared options. Ruth's coordinator selects Structural Engineering, saves, then reads the custom-value map to check that the stored representation agrees with the option selected. Sending a misspelled field key refuses the aggregate instead of adding a second discipline property. If a later integration corrects a different named key, Professional Discipline remains. If administrators make another field required after Ruth was created, her unrelated phone correction can still save while that older value is absent; attempting to clear an already present required value is a different validation case. Definition maintenance belongs to Platform.
Why It Works This Way
Our reading is that definitions supply the meaning of values while CRM owns their placement on actual records. Merging named keys avoids turning a partial integration payload into an accidental purge of unrelated customer information. Rejecting undeclared or wrong-kind keys prevents misspellings and foreign definitions from silently becoming business data.
Declared conversion keeps list choices, references, and numeric values usable across presentation and queries. Preserving older records that lack a newly required value separates forward validation from a retroactive repair requirement. Restricting custom values to supported parent records prevents a flexible data mechanism from expanding the affiliation and role model without an explicit product contract.
Relationships
Platform metadata owns custom field definitions and the shared editing and rendering vocabulary. CRM contacts and organizations own the corresponding record values. Save corrections without overwriting another change provides aggregate rollback when conversion fails. Locate people and organizations returns readable values, and Platform query and record-view systems consume the declared model through their contracts.