Record Protection and History
What It Is
Record Protection and History is the set of safeguards and retained explanations that surrounds contact and organization changes. Staff encounter it as a record version, archive state, lock, or revision timeline. These facets answer separate questions: whether an edit is current, whether the record is available for ordinary work, whether it can be changed, and what happened earlier.
Customer locks can also protect individual owned elements, and contact roles have supported lock administration. Rhythm's protected system records express a stronger authority than customer locks. The mechanism exists, but no current CRM seed is protected. Revisions capture attributed committed differences; they are evidence about changes, not editable replacements for live records.
Why It Exists
Our reading is that durable identity data needs a trustworthy explanation of change as well as validation of its present values. Staff can open old information while another person or a worker changes it. A closed organization can still explain historical affiliations. Distinct safeguards let the association preserve context and control corrections without making every preservation decision a deletion or every lock irreversible.
What It Is Not
A version is not a reservation that prevents another editor from working. A lock is not ordinary access permission: an authorized editor can still encounter a protected record. Archive is not a business status and does not erase relationships. A revision is not a recoverable backup or a restore command. Protected system configuration is also distinct from a customer lock that administrators can release.
What It Controls
Versions govern whether field-changing requests are based on the current record. Real changes advance them, including relevant system changes; unchanged current saves do not. Locks constrain updates or deletion, and owned-element locks prevent parent operations from bypassing protected details. Dedicated archive actions govern availability independently of record status and preserve the record's existing information.
History commits attributed revisions and provides separately authorized reads, including retained evidence for deleted records. Customer lock actions record their own reasons and before-and-after restrictions. Protected system records refuse customer lock, unlock, and delete actions while ordinary fields can remain editable. These are complementary effects rather than one lifecycle flag that every operation interprets identically.
How It Is Used
The CRM Editor saves against the version read and reloads or compares after a conflict. The CRM Administrator chooses archive, restore, deletion, or lock changes according to the actual need and authority. The CRM Reader inspects permitted revisions and current or archived information. Archive a closed organization and inspect its retained history illustrates preservation of an identity used by past work.
Good use keeps action and explanation connected. An administrator records why a lock changes, and a coordinator distinguishes a system-attributed update from a colleague's correction. An integration does not bypass a lock or archive simply because it uses the service. History supports investigation without promising that earlier information can be restored automatically.
Example
Two coordinators edit Ruth's contact. One saves a corrected phone; the other's older title correction conflicts. Reloading preserves the first change and lets the second save deliberately. History then explains the committed edits rather than recording a silent overwrite or another entry for an unchanged round trip.
Separately, Harbor Engineering closes with ended affiliations still referring to it. An administrator archives it instead of deleting its context. Direct reads and past affiliations remain available, ordinary selection excludes it, and authorized restoration can make it available again. The revision explains that lifecycle action without changing the organization's business status.
How It Relates
Contact and Organization carry versions, lifecycle state, and captured revisions. Affiliation and contact-detail elements participate in aggregate locks and changes rather than becoming independent protection concepts. Platform security owns authority evaluation, Platform identity supplies actor names, and Platform files owns storage retirement. Data Quality owns merge survivors. Workspace lifecycle owns purge, which defines the end of revision retention rather than ordinary record deletion.