--- id: CON-PFM-TNL-005 name: Deletion Request feature: FEAT-PFM-TNL-05 product_area: platform module: tenant-lifecycle revision: 2 status: draft product_intent: confirmed implementation_evidence: observed source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 services-crm: a8d1364f1dd44b723bb5f9acba12f983e9ec8d69 services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b services-committees: 36129c24daeaadcdb339218c38cdeaff9861359d services-membership: 5994c270e8a37a30f848e99ba5b5ee6b87c08893 services-submissions: 64236c19be89579ef5897aad7de3925ed3ce03bf services-websites: 5fc6823c69d5e6f208c21dba8c0eb3132f8bdc4c services-marketing: d071a159fe9782bb71ff246d5c67d5bbfe07fbfa definition: >- A deletion request retains the decision, eligibility and outcome of deliberate workspace removal. owned_by: MOD-PFM-TNL synonyms: - workspace deletion - deprovisioning not_to_be_confused_with: - disabling customer access - the watcher and purge executions facets: - name: Request state meaning: >- Scheduled, held, cancelled, executing, failed and completed explain what action remains possible. Only one open request can exist for a workspace. used_for: Identifying whether preservation is still possible. - name: Eligibility meaning: >- Standard, never-activated and disposable-test paths calculate the recorded wait. Later settings do not recompute that date. used_for: Fixing the time available for review. - name: Confirmation and explanation meaning: >- Typed workspace-name confirmation reduces mistaken selection. The reason and reviewed version make the decision accountable. used_for: Reducing mistaken selection and stale decisions. - name: Hold and release meaning: >- A hold preserves eligibility while stopping progression. Release supplies at least three further days and another final reminder. used_for: Resolving questions before destruction. - name: Notices meaning: >- The internal staff list and requester receive notices for the request, changes and outcome. Required delivery states gate destruction; record deduplication does not guarantee a single message under every failure. used_for: Keeping staff aware and gating removal. - name: Irreversible boundary meaning: >- The locked recheck and committed purge job separate cancellable waiting from destruction. used_for: Separating reversible waiting from irreversible work. - name: Removal and verification meaning: >- Participants remove resources in batches, and inventory supports completion. Blocked resources and incomplete declarations limit that evidence. used_for: Establishing the declared removal result. - name: Retained record meaning: >- Counts, actors and dates remain on the request, with completed deletion mirrored to an external ledger for identifier retirement and restore recovery. used_for: 'Supporting audit, retirement and restore recovery.' relationships: - to: CON-PFM-TNL-001 statement: Deletion controls the workspace’s progression toward removal. provenance: observed source: 'services-platform:modules/tenants/services/deletion/begin-destruction.ts' - to: CON-PFM-TNL-003 statement: Participant inventory and purge provide the request’s removal evidence. provenance: observed source: >- services-platform:modules/tenants/services/deletion/tenant-purge-operations.ts lifecycle: - state: scheduled meaning: The request awaits its recorded eligibility and guards. how_it_changes: 'Hold, cancellation or destruction changes its state.' - state: held meaning: A pause prevents destruction regardless of the date. how_it_changes: Release restores scheduling; cancellation ends the decision. - state: cancelled meaning: The decision ended without destruction and remains in history. how_it_changes: Another deletion needs a fresh request. - state: executing meaning: Removal has passed the preservation boundary. how_it_changes: Verification completes it or failure requires recovery. - state: failed meaning: The interrupted purge leaves the workspace deleting. how_it_changes: Staff submit a replacement purge attempt. - state: completed meaning: Removal evidence and retired identity remain after the workspace is gone. how_it_changes: The record persists as completed history. acted_on_by: - CAP-PFM-TNL-013 - CAP-PFM-TNL-014 - CAP-PFM-TNL-015 - CAP-PFM-TNL-016 - CAP-PFM-TNL-017 - CAP-PFM-TNL-018 visible_to: - ACT-PFM-004 - ACT-PFM-039 - ACT-PFM-012 evidence: - >- Inspected source: services-platform:modules/tenants/services/deletion/begin-destruction.ts - >- Inspected source: services-platform:modules/tenants/services/deletion/tenant-purge-operations.ts supersedes: [] intent_sources: - >- services-platform:docs/tenants/tenant-lifecycle-plan.md#§5 (approved 2026-10-09) --- # Deletion Request ## What It Is A deletion request is the retained decision to remove a customer workspace after an announced waiting period. It records who requested removal, why, the workspace and customer identity, and when destruction may become eligible. The request survives the workspace it describes, providing an account of the decision and its result. The request carries preservation and destruction in one understandable lifecycle. Before execution, staff can pause or cancel it. At the point of no return, current facts are rechecked and the purge job is recorded with the destruction decision. After that commit, cancellation cannot promise to preserve records already being removed. ## What It Is Not Disabling a workspace does not request deletion. It closes customer access and is a prerequisite for the request, while retaining the data. Cancellation also does not re-enable customer access; staff decide that separately. The request differs from its schedule and purge jobs. Those jobs watch the date or remove resources, while the request retains the authoritative decision, state and history. A completed live deletion is not immediate backup erasure, and an empty database inventory does not establish removal of resources the plan never reached. ## How It Is Used Authorized staff disable an eligible workspace, confirm its exact name and submit a reason against the version they reviewed. The request fixes its waiting period and schedules notices. Support can hold it while a commercial or operational question is answered, then release it with additional time. Staff can cancel while it remains scheduled or held. The schedule checks notices, eligibility, workspace conditions and the requester’s current authority before destruction. A temporary obstacle makes it wait. Lost requester authority holds the request for review. A failed purge keeps the workspace in destruction and needs staff recovery rather than pretending that removal completed. ## Its Facets **Request state.** Scheduled, held, cancelled, executing, failed and completed explain what action remains possible. Only one open request can exist for a workspace. **Eligibility.** Standard, never-activated and disposable-test paths calculate the recorded wait. Later settings do not recompute that date. **Confirmation and explanation.** Typed workspace-name confirmation reduces mistaken selection. The reason and reviewed version make the decision accountable. **Hold and release.** A hold preserves eligibility while stopping progression. Release supplies at least three further days and another final reminder. **Notices.** The internal staff list and requester receive notices for the request, changes and outcome. Required delivery states gate destruction; record deduplication does not guarantee a single message under every failure. **Irreversible boundary.** The locked recheck and committed purge job separate cancellable waiting from destruction. **Removal and verification.** Participants remove resources in batches, and inventory supports completion. Blocked resources and incomplete declarations limit that evidence. **Retained record.** Counts, actors and dates remain on the request, with completed deletion mirrored to an external ledger for identifier retirement and restore recovery. ## How It Relates The request moves workspace lifecycle into pending deletion and destruction. Participants supply removal and inventory, while the job engine supplies durable execution. Customer administration controls disabling and ordinary records. The external ledger preserves evidence across database restores, and backups follow their separately documented expiry period. ## What It Could Become The product should close the gaps around restored access, CMS removal and remote declaration drift before relying on complete destruction. More dependable notice delivery and removal accounting also need explicit failure scenarios. Any future customer-facing notice or faster backup erasure remains a separate product choice.