Remove records and their owned information
Purpose
Some records must be removed from the live CRM rather than retained in archive. This capability performs hard deletion under explicit authority, checks owned-element protection and organization dependencies, and removes the record's owned information together. It explains today's deletion boundary without implying that the broader safe-delete impact preview has already shipped.
How It Works
An authorized delete checks the parent and owned-element locks. Deleting a contact removes its details, preferences, custom values, affiliations, and role rows in the transaction, releases the primary e-mail, and leaves subsequent live reads missing. Record history and number nonreuse survive that removal. A surviving spouse loses the deleted-person reference through a separately attributed system change and version advance.
Organizations cannot be deleted while children or affiliations depend on them, including ended and future ties. Archive is available when historical dependencies make deletion inappropriate. When enabled, Platform's associated custom-record ownership rules can detach, cascade, or refuse inside the transaction; the disabled mode performs no such call.
The transaction detaches the contact photo or organization logo, and later cleanup retires the asset with its expiry. Record-page console actions offer archive, while service and bulk hard deletion remain available until safe delete. These paths are distinct from a reversible lifecycle choice.
Example
An administrator tries to delete a closed member firm that still appears in a former employee's past affiliation. The service identifies the dependency and retains the complete organization. She archives it instead. For an unrelated contact eligible for deletion, a successful service delete removes owned entries and releases its primary address while retaining the revisions staff may inspect under history authority.
For Harbor Engineering, even an ended affiliation is a dependency. The administrator checks the named blocker rather than assuming that zero current staff makes the firm deletable. Archive retains the firm as a historical reference. For Daniel Ruiz's independently deletable contact, a locked phone still blocks deleting the whole person; the administrator needs the appropriate release before trying again. After a permitted delete she checks that the live read is missing and that the retained history remains available under its separate authority. If Daniel had a spouse link, the surviving person's next read has a new system-attributed version, so an already-open editor must recover from that change.
Why It Works This Way
Our reading is that aggregate deletion prevents a missing parent from leaving apparently live contact details or responsibilities behind. Any element lock must block the whole operation because deleting its parent would otherwise bypass the protection. Organization dependencies include history because an ended relationship still needs the organization's identity to explain it.
Keeping revisions and number nonreuse preserves an account of what was removed without pretending the live record still exists. System attribution on a spouse update explains why another record changed during deletion. Transactional asset detachment and later retirement distinguish database success from storage cleanup. The optional ownership integration is a stated boundary, not evidence that every dependent application has a complete safe-delete policy today.
Relationships
Set records aside and restore them provides preservation when hard deletion is unsuitable. Record locks and system protection supply blockers. History provides retained audit reads after the live record disappears. Platform files performs storage retirement, and Platform metadata supplies associated custom-record ownership rules when enabled. Data Quality owns merges; deletion does not create a merge survivor or replace that identity-change process.