Rhythm 2.0 Specifications

Appearance

CAP-PFM-TNL-014Pause or cancel deletion while preservation remains possible

Markdown

CAP-PFM-TNL-014

Pause or cancel deletion while preservation remains possible

Markdown
  • DocumentDraft
  • Product intentConfirmed
  • ImplementationObserved

Planning

Feature
FEAT-PFM-TNL-05
Exercised by
FAS-PFM-TNL-02-02, FAS-PFM-TNL-05-01, FAS-PFM-TNL-05-02, FAS-PFM-TNL-05-03, FAS-PFM-TNL-05-04, FAS-PFM-TNL-05-05
Key concepts
CON-PFM-TNL-005
Actors
ACT-PFM-039, ACT-PFM-004
Journeys
JNY-PFM-TNL-004
Depends on
CAP-PFM-TNL-013
Related
CAP-PFM-TNL-015, CAP-PFM-TNL-016
Proved by
ATS-PFM-TNL-014

Implementation

Executable suites
TST-PFM-TNL-062

KindCapabilityProduct areaPlatformModuleWorkspace Lifecycle Across ApplicationsRevision2

Read atservices-platform ad3f6a65

Pause or cancel deletion while preservation remains possible ​

Purpose ​

Staff can hold, release or cancel a deletion until destruction becomes irreversible.

How It Works ​

Support can hold a scheduled request while a question is resolved. The hold records a reason without changing the eligibility date. Release returns it to scheduled and gives it at least three days from release. The revised schedule owes another one-day reminder. Authorized staff can instead cancel a scheduled or held request. Cancellation returns the workspace to active but does not restore customer access. Each action checks the version staff read and records its own notice. Once destruction is executing, these actions are refused even when the version is stale. Staff can inspect the request and its notices to understand what decision remains possible.

Relationships ​

  • Schedule deliberate workspace deletion: Its result establishes the state or declared resources needed by this operation.
  • Keep deletion decisions visible to staff: The capabilities share the workspace’s recorded lifecycle decision.
  • Revalidate the irreversible deletion decision: The capabilities share the workspace’s recorded lifecycle decision.

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes
Holding preserves the date and release leaves at least three days.Cancellation restores active lifecycle while retaining disabled status.Each action retains its actor, explanation and notice obligation.
Surfaces
consoleapi
Intent sources
services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.2services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.4services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.8

Controls

26 controls apply, from the corpus control catalogue.

TC-AVL-004 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-DAT-004 TC-DAT-005 TC-IAM-001 TC-IAM-006 TC-LOG-001 TC-LOG-004 TC-LOG-005 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-004 TC-PI-005 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-VEN-001 TC-VEN-002 TC-VEN-003

Permissions

KeyChecked atScope
platform.tenants.deletion-holdapiglobal
platform.tenants.deletion-cancelapiglobal
platform.tenants.deletion-readapiglobal

Business Rules

8 rules, 7 to be proved before approval. A rule's product intent is derived from its origin: 8 confirmed by a product decision, the rest inheriting this capability's confirmed.

IdRuleKindEnforced atProvenance
01must prove
Confirmed
Hold and release require staff hold authority, cancellation requires staff cancel authority, and customer administrators cannot perform these actions or inspect requests.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.2 (approved)
proved by ATS-PFM-TNL-014-01
permissionapi, servicetest
services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#may not cancel a deletion request
02must prove
Confirmed
Each action includes a ten-to-two-thousand-character reason and the reviewed request version; changed versions refuse the action.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§8.2 (approved)
proved by ATS-PFM-TNL-014-02
validationapi, servicetest
services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#refuses a request that has changed since the screen was drawn
03must prove
Confirmed
Holding a scheduled request records actor, time and reason while preserving eligibility and workspace lifecycle; other request states refuse holding.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.1, §5.2 (approved)
proved by ATS-PFM-TNL-014-03, TST-PFM-TNL-062
lifecycleservice, databasetest
services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#leaves the date alone: a hold stops the clock rather than moving it
04must prove
Confirmed
Release schedules eligibility at the later of its previous date and three days after release, with a new one-day reminder.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.1 release (approved)
proved by ATS-PFM-TNL-014-04, TST-PFM-TNL-062
calculationservicetest
services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#pushes the date out three days when the original is nearly here
05must prove
Confirmed
Cancellation closes a scheduled or held request and restores active lifecycle while leaving the workspace disabled.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.4 Cancel (approved)
proved by ATS-PFM-TNL-014-05, ATS-PFM-TNL-014-07
lifecycleservicetest
services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#leaves the tenant disabled: calling off a deletion restores nobody access
06must prove
Confirmed
Executing requests reject hold, release and cancellation before evaluating stale versions, preserving the destruction decision.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.4 (approved)
proved by ATS-PFM-TNL-014-06
validationservicetest
services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#refuses to cancel a request whose destruction has begun
07must prove
Confirmed
Every hold, release and cancellation creates its corresponding notice obligation.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.5 Reminder schedule (approved)
no proof recorded yet
policyservicetest
services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#owes a notice, because a schedule that changes silently is a schedule nobody can trust
08
Confirmed
Staff page through requests filtered by state or workspace in eligibility-and-identifier order and inspect each request’s notices.
origin: services-platform:docs/tenants/tenant-lifecycle-plan.md#§5.8 Listing, §8.2 (approved)
policyapi, servicetest
services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#reads the notices it owes beside it

Scenarios

IdGivenWhenThenProvenance
01Finance needs additional time for an export.Support holds the request and later releases it.Destruction waits during the hold and release schedules at least three further days with a reminder.test
services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#pushes the date out three days when the original is nearly here
02The customer resumes its relationship with Rhythm.Staff cancel the deletion.Active lifecycle returns, but separate staff re-enablement is still required.test
services-platform:modules/tenants/tests/e2e/tenant-deletion-requests.e2e.spec.js#returns the tenant to active, read back through the tenants API

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.

Rhythm Software