Delete a contact or an organization
What It Does
Deletion removes a live contact or organization and its owned information while retaining the explanation of the removal. An administrator removing an erroneous person expects its details and affiliations to disappear together; deleting an organization also requires proving that children and people no longer depend on its identity.
Our reading is that the workflow needs separate boundaries for dependency policy, committed deletion and file retirement. Captured history survives the live owner, while downstream search removal and eventual asset cleanup can lag. Archive remains a different capability when staff need to preserve an identity for historical relationships.
What Starts It
An authorized administrator or record operation asks to remove a live person or organization. Bulk and merge work can enter the same persistence boundary. The caller’s request starts dependency and restriction checks; it does not establish permission to erase every external projection or retained revision. An organization with remaining children or affiliations requires resolution of those dependencies first.
The Flow
The diagram shows the sequence and service seams. Each synchronous stage waits for its result, while captured-event, queue and scheduled stages can run after the originating request has returned. The hop descriptions below identify the write and failure boundary, so the last arrow must not be mistaken for one atomic transaction across every participant.
Hop by Hop
1. Entities route
The route requires the record’s administrative delete grant and recognizes merged or absent identities before persistence. A merged-id response points the caller toward the survivor; it is not authority to delete that survivor silently. Record access and the route’s grant remain the entry checks.
2. Entities persistence (one transaction)
Persistence locks the subject and checks owner restrictions, nested deletion locks and Rhythm protection. For an organization it also checks children and affiliations of every date. A blocking dependency prevents the local delete rather than cascading people’s relationships into missing organizational context.
3. Platform associations (inside the same transaction)
When enabled, Platform association deletion policy runs inside the same transaction and applies restrict, detach or cascade decisions. A restrictive policy rolls back the whole removal. When this integration is disabled, the flow does not establish cleanup of every external custom-record association.
4. Entities persistence (same transaction)
The transactional removal clears a surviving spouse with system attribution and deletes owner and cascading children. It also settles applicable duplicate bookkeeping and attention, detaches file references and removes source mappings. These local effects either commit together or roll back together.
5. Database change capture
Database capture retains the subject’s deletion explanation without requiring a live foreign-key owner. Missing capture attribution aborts the transaction. Authorized history inspection can therefore examine the removed aggregate even when ordinary record reads find nothing.
6. CRM change-event consumers
Consumer messages recalculate organizations affected by a deleted person and remove or refresh the relevant projections. A failing search or compliance reaction can leave a stale dependent view. Queue retries apply to that reaction rather than recreating or repeating the successful record deletion.
7. Asset cleanup sweep and consumer
The asset sweep claims detached file work and queues retirement. Before deleting a file, the consumer checks references again and moves eligible content into expiring deleted storage. Failure leaves observable cleanup state and queue evidence; removing a CRM record is not instant physical erasure of every file.
When Something Fails
Hop 1 — Entities route
The failure boundary is: Return authorization, absent-record or merged-record refusal before deletion. The remaining work or data is: No partial business write remains. The caller receives the result.
Hop 2 — Entities persistence (one transaction)
The failure boundary is: Return the blocking protection, lock or dependency without removing the record. The remaining work or data is: No partial business write remains. The caller receives the result.
Hop 3 — Platform associations (inside the same transaction)
The failure boundary is: A restrictive association policy aborts the entire deletion. The remaining work or data is: When disabled, associated custom records can retain references to the removed endpoint. Association policy errors and remaining Platform data show the gap.
Hop 4 — Entities persistence (same transaction)
The failure boundary is: Roll back the complete delete transaction if any step fails. The remaining work or data is: No partial business write remains. The caller receives the result.
Hop 5 — Database change capture
The failure boundary is: Capture failure aborts deletion. The remaining work or data is: No partial business write remains. History permission permits inspecting the retained deletion revision.
Hop 6 — CRM change-event consumers
The failure boundary is: Retry failed handler messages, then dead-letter after five receives. The remaining work or data is: Search can still show deleted data and organization compliance can remain stale. Consumer logs and dead-letter messages identify failed reactions. This failure is downstream of committed input; operators investigate its own delivery rather than treating the caller’s original save as failed.
Hop 7 — Asset cleanup sweep and consumer
The failure boundary is: Retry cleanup messages; terminal failures retain failed rows and dead-letter messages. The remaining work or data is: Files remain until a successful cleanup and later storage expiry. Cleanup logs, state rows and its dead-letter queue expose unresolved files. A later attempt can be required; the scheduling or publication boundary does not establish an immediate user-visible completion.
Repeats and Races
Delete has no version argument. A second request after success receives not-found or merged-identity handling rather than a recognized replay response. Owner locking orders it against an in-flight save, and reciprocal spouse cleanup shares the contact transaction. These properties do not imply compare-and-delete semantics or universal deadlock freedom.
Bulk jobs use the same record guards and report refusals per item. Merge uses the persistence boundary but must also respect the enabled association policy. Cleanup and downstream reactions tolerate an already-absent subject without recreating it. Files remain until successful retirement and later storage expiry.
What Is Observable
The caller receives the result. Association policy errors and remaining Platform data show the gap. History permission permits inspecting the retained deletion revision. Consumer logs and dead-letter messages identify failed reactions. Cleanup logs, state rows and its dead-letter queue expose unresolved files.
The person or initiating caller sees the synchronous result at its own boundary. Captured history establishes committed local changes; logs, durable job state and queue outcomes explain remaining work. A successful database change, accepted downstream request and completed delivery are different observations and must be investigated through the component that owns each one.
Open Design Questions
The enabled association-deletion boundary and post-commit projection or file recovery limits remain existing findings. Ordinary deletion is not workspace purge, and retained revisions intentionally survive it. The evidence does not support a promise that every external association, index entry or physical file disappears with the response.