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.