Record Protection and History
Overview
Record Protection and History preserves the meaning of a CRM record while people and automated processes change it. Staff need to know whether an edit is based on current information, whether a record is deliberately protected, and what earlier changes explain its present condition.
Different operations answer different needs. Archive sets a record aside while retaining it; deletion removes the live record; locks constrain changes; history preserves attributed revisions. Combining these into one status or one destructive action would hide distinctions that staff need to make deliberately.
Why It Exists
Our reading is that shared CRM information needs safeguards beyond validating a single form. A coordinator can open Ruth's record before another editor corrects her phone; saving the older form without a version comparison could erase that correction. A firm can close while ended affiliations still need its identity to explain former employment. Deleting every closed body would remove that context.
Versions, archive, customer locks and attributed history address these different risks. A version checks what the editor has read; archive changes ordinary availability; a lock restricts mutation; history explains committed changes. Keeping their meanings separate gives staff a deliberate choice and helps later investigation. The recorded complete-payload and safe-delete boundaries remain visible rather than being inferred as completed safeguards from the existence of save or delete operations.
Who Uses It
The CRM Editor saves corrections and resolves conflicts. The CRM Reader inspects permitted revisions and retained record information. The CRM Administrator archives, restores, deletes, or changes locks under the specific authority each action requires. The Data Importer must respect the same version and lifecycle constraints, and the CRM System contributes separately attributed changes.
How It Works
A save carries the version read. Rhythm checks the current record, validates the resulting aggregate, and commits the change and its revision together. A stale edit receives a conflict; a current unchanged save leaves version and history alone. The approved complete-payload replacement policy remains a recorded implementation gap, distinct from today's omission behavior.
Archive hides a record from ordinary discovery and prevents ordinary editing while preserving its status, collections, and relationships. Authorized restoration makes it available again. Locks and protected records add separate restrictions. Hard deletion remains a service and bulk operation with dependency checks, while record-page actions offer archive. Revisions remain readable under history authority after deletion and are not a restore mechanism.
An editor begins with the record version she actually read. The service applies a patch to that record or interprets a replacement under its existing omission rules, validates the resulting aggregate, and commits all owned changes together. An invalid element, lock or stale version leaves the prior aggregate intact. On conflict, the contact editor offers reload or comparison. Keep Editing does not silently adopt the latest version. The person must review current information before submitting against it, including when a system change rather than a colleague caused the conflict.
Current unchanged saves avoid new revisions. Stale unchanged saves still conflict under today's behavior, a separately recorded product question. Product's approved complete-payload replacement requirement is also separate from the implementation: a replacement currently can clear omitted values, with preservation exceptions for affiliations, custom values and other stated cases. Clients must understand that gap rather than infer that every omission is already rejected. The console's changed-field patch workflow does not certify that the service replacement gap has disappeared.
Archive is a preservation choice. It retains identity, status, collections and relationships while excluding the record from ordinary discovery and refusing ordinary editing. Restoration requires the specific action and current version. A customer full lock can block updates as well as deletion; a delete lock still permits ordinary correction. Releasing a restriction uses authorized audited actions with a reason. System protection belongs to another authority and cannot be released by customer unlock permission, although its ordinary fields have their documented editing boundary. The pinned seeds contain no protected CRM record.
Hard deletion removes the live record and owned information subject to blockers, including organization affiliation dependencies. Record pages offer archive, while service and bulk paths retain deletion. The broader safe-delete impact workflow is not complete here. History survives live-record deletion and groups old and new values with attribution; it supports explanation, not restoring a snapshot. Current display labels and captured fallbacks must also be distinguished from a promise that every related name is historically frozen.
Examples
A closed member firm still appears in former employees' ended affiliations. An administrator cannot delete it while those dependencies remain, so she archives it with a reason. Ordinary discovery no longer offers it, but opening it directly retains its information and affiliation context. If it reopens, authorized unarchive restores availability without reconstructing the firm or its ties.
Two coordinators open Ruth's contact. Elena saves the corrected phone first; Sam's later title edit is refused as stale. Sam compares, reloads the corrected phone, reenters the title and saves against the latest version. The resulting history explains both changes. If a spouse cleanup made the intervening change instead, the conflict identifies the system; it does not silently merge Sam's edit over it.
An administrator places a delete lock on Harbor West Chapter while retention is being reviewed. Ordinary correction remains possible, but deletion does not. She later releases the restriction with a current version and recorded reason. When the chapter closes, ended affiliations still name it. Dependency checks prevent hard deletion, and archive preserves those references while taking the chapter out of ordinary discovery. Opening it directly explains the closed organization's context. If it reopens, unarchive returns the same identity to availability. Staff inspect retained history without assuming that reading an earlier value offers a rollback action.
Decisions and Tradeoffs
Our reading is that a version protects the editor's knowledge of the whole record. Automatically accepting the latest token would make an unreviewed change look authorized. Atomic aggregate validation prevents a refused address or affiliation from leaving a partly corrected person behind; no-op handling prevents unchanged submissions from obscuring meaningful history.
Archive, locks and protection preserve different invariants. Combining them into one inactive status would obscure whether a record is unavailable for selection, temporarily immutable, or reserved by system authority. Hard deletion and archive likewise have different consequences for dependent history. Keeping deletion available does not make it the safe choice for every closed body, and the deferred safe-delete boundary must remain visible. These are interpretations of the formal behavior rather than an invented history of design deliberation.
Scope and Boundaries
The feature owns version-aware record saves, archive state, hard-deletion behavior, customer locks, system protection, and revision reads. Platform security owns permission evaluation, and Platform files owns storage cleanup. Data Quality owns merge decisions and survivors. The broader safe-delete architecture remains an intended boundary; it must not be presented as a completed impact-preview workflow here.
Outcomes
Staff can protect records, explain their changes, and handle closed or obsolete identities without confusing archive with deletion. The Record Protection and History acceptance suite joins concurrency, lifecycle, locks, and audit outcomes. Archive a closed organization and inspect its retained history provides a staff narrative for preservation, with unresolved safe-delete and protection choices kept visible in findings.
Its Capabilities
Save corrections without overwriting another change anchors edits to the version read. Set records aside and restore them manages archive independently of status. Remove records and their owned information performs checked hard deletion. Control record locks and system protection distinguishes customer restrictions from Rhythm protection. Inspect a record’s changes over time exposes attributed revisions. The archive journey shows preservation across these safeguards.