Custom Record
What It Is
A custom record is one item in an organization-defined register. A Boat object defines the shared structure; the record for Miss Belle holds that boat’s particular information. Rhythm derives a recognizable name and number and keeps typed property values under the object’s definitions.
Records can also carry relationships, external identities and optional publication states. Archival and deletion are separate choices. History and business events provide different accounts of change: revisions support inspection of prior information, while events let subscribers react to supported committed operations.
Why It Matters
Staff need to enter trustworthy information without bypassing the definition they share. Service validation protects type, required values, conditional rules, references and uniqueness. Version checks let two people work on the same item without silently replacing each other’s changes.
Retained history helps people understand corrections and lifecycle actions. External identities help integrations recognize an existing record on a later load. Relationship policies prevent a deletion from disregarding another record’s dependence on the item being removed.
How It Works
A caller with suitable object reach creates or changes records while the object is active. The service validates the resulting values and reports property-specific problems without echoing rejected content. Creation can fill compatible defaults, and references must resolve to suitable existing records.
Patch retains omitted properties; replacement clears omitted live properties. Derived names combine configured components or fall back to the prefixed number. Numeric values use scaled storage within the supported safe range, and normalized unique reservations protect equivalent text values.
Visibility checks reject changed hidden values rather than automatically clearing untouched hidden information. A driver-only change can therefore retain a previously stored value. This is an examined implementation distinction that needs a product decision rather than a broader promise that every save removes hidden content.
What It Contains
Property values, derived name and number, version, publication, archival, history, business events and external identity are the record’s main facets. Image and file values add managed attachments prepared before the record mutation. Failed preparation identifies the property without disclosing the supplied address.
Publication time follows the published state. Archival retains information and removes the record from ordinary browsing; it blocks ordinary edits and publication changes. Direct deletion remains possible for an unlocked archived record while its object is active, subject to the usual relationship and version checks.
What It Is Related To
The custom object supplies the definition and operating settings. Custom fields and their rules govern property values. Links connect the record to contacts, organizations and other custom records, and endpoint policies determine whether deletion detaches, cascades or refuses.
History retains revisions even after deletion under its own access contract. The business-event ledger and delivery work support asynchronous consumers. Loads reuse the ordinary write contract, while their source identity and validated impact support repeatable integration work.
What Needs Deciding
The product should settle the intended treatment of untouched hidden values and deletion of archived records. Event retention and dependency ordering also need focused proof beyond broad lifecycle tests. Design should keep record history, business announcements and audit separate, because their payloads, consumers and no-op behavior do not establish an identical account of every write.