---
id: ATS-PFM-TNL-015
scope: CAP-PFM-TNL-015
product_area: platform
module: tenant-lifecycle
revision: 2
status: proposed
approved_by: null
approved_at: null
source_sha:
  services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1
scenarios:
  - id: ATS-PFM-TNL-015-01
    title: Reminder timing follows the chosen wait
    level: unit
    proves:
      - BR-CAP-PFM-TNL-015-01
    preconditions: 'The fixture covers long, boundary and short waiting periods.'
    steps: Calculate request notice obligations.
    expected: >-
      Seven-day reminders require at least eight days and final reminders become
      immediate below two days.
    negative: false
    data_needs: >-
      Use the workspace, caller and collaborator fixtures declared by the bound
      tests.
    bound_to:
      - >-
        services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#owes
        the notice at request, the seven-day reminder and the one-day reminder,
        in that order
      - >-
        services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is
        owed at exactly eight days, the shortest period with room for it
      - >-
        services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is
        skipped just below eight days, where it would fall before the request
        itself
      - >-
        services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is
        due at once just below two days, so a short period still has the notice
        destruction waits for
      - >-
        services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is
        due at once for a one-day period, the never-active tenant
      - >-
        services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#makes
        both of those notices due at once, or a tenant with a one-day period
        could never be deleted
    provenance: test
    source: >-
      services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#owes
      the notice at request, the seven-day reminder and the one-day reminder, in
      that order
  - id: ATS-PFM-TNL-015-02
    title: State changes create notice obligations
    level: api
    proves:
      - BR-CAP-PFM-TNL-015-02
    preconditions: 'Fixtures exercise hold, release, execution, completion and failure.'
    steps: Inspect notice obligations after each event.
    expected: Each event retains the corresponding notice kind.
    negative: false
    data_needs: >-
      Use the workspace, caller and collaborator fixtures declared by the bound
      tests.
    bound_to:
      - >-
        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
      - >-
        services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#owes
        a released notice
      - >-
        services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#owes
        a cancelled notice
      - >-
        services-platform:modules/tenants/tests/integration/services/deletion/begin-destruction.integration.spec.js#owes
        an executing notice, so somebody is told the point of no return was
        passed
      - >-
        services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#tells
        the people the plan owes a last notice to
      - >-
        services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge-recovery.integration.spec.js#tells
        the people a deletion that failed was not completed
    provenance: test
    source: >-
      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
  - id: ATS-PFM-TNL-015-03
    title: Recipients remain internal
    level: api
    proves:
      - BR-CAP-PFM-TNL-015-03
    preconditions: The request advances through its waiting period.
    steps: Inspect captured recipients for each notice.
    expected: >-
      Recipients are the staff list and requester, with no customer-facing
      addition.
    negative: false
    data_needs: >-
      Use the workspace, caller and collaborator fixtures declared by the bound
      tests.
    bound_to:
      - >-
        services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#tells
        the staff list and the requester, and nobody else
    provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#tells
      the staff list and the requester, and nobody else
  - id: ATS-PFM-TNL-015-04
    title: Notice slots deduplicate recorded obligations
    level: api
    proves:
      - BR-CAP-PFM-TNL-015-04
    preconditions: A thirty-day request is scheduled.
    steps: Run its notice schedule and append an existing slot again.
    expected: >-
      Notices occur at their due times and repeated slot insertion adds no
      duplicate record.
    negative: false
    data_needs: >-
      Use the workspace, caller and collaborator fixtures declared by the bound
      tests.
    bound_to:
      - >-
        services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#sends
        the requested notice on the day of the request
      - >-
        services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#sends
        both reminders, each on its own day, as the waiting period passes
      - >-
        services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#slept
        until each notice was due rather than polling, and never for a fixed
        duration
      - >-
        services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#ignores
        a notice whose schedule slot is already taken, so a re-run sends nothing
        twice
    provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#sends
      the requested notice on the day of the request
  - id: ATS-PFM-TNL-015-05
    title: Failed gating notices prevent destruction
    level: api
    proves:
      - BR-CAP-PFM-TNL-015-05
    preconditions: >-
      A required notice has failed and another fixture is
      environment-suppressed.
    steps: Advance schedules beyond eligibility.
    expected: >-
      Failure continues waiting with the notice identified, while suppression
      satisfies the gate.
    negative: true
    data_needs: >-
      Use the workspace, caller and collaborator fixtures declared by the bound
      tests.
    bound_to:
      - >-
        services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#holds
        the deletion indefinitely when a notice could not be delivered, rather
        than destroying the tenant unannounced
      - >-
        services-platform:modules/tenants/tests/integration/services/deletion/begin-destruction.integration.spec.js#waits
        while a notice destruction waits for has not been sent
      - >-
        services-platform:modules/tenants/tests/integration/services/deletion/begin-destruction.integration.spec.js#names
        the notices it is waiting for
      - >-
        services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#counts
        a suppressed notice as sent, which is the development and test path
      - >-
        services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#still
        lists a failed notice, so a send that never worked never lets a tenant
        be deleted
      - >-
        services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#ignores
        a seven-day reminder that was never sent: only two kinds gate
        destruction
    provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#holds
      the deletion indefinitely when a notice could not be delivered, rather
      than destroying the tenant unannounced
evidence:
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#owes
    the notice at request, the seven-day reminder and the one-day reminder, in
    that order
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is
    owed at exactly eight days, the shortest period with room for it
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is
    skipped just below eight days, where it would fall before the request itself
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is
    due at once just below two days, so a short period still has the notice
    destruction waits for
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/unit/services/deletion/waiting-period.spec.js#is
    due at once for a one-day period, the never-active tenant
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/deletion/request-deletion.integration.spec.js#makes
    both of those notices due at once, or a tenant with a one-day period could
    never be deleted
  - >-
    Inspected source:
    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
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#owes
    a released notice
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/deletion/deletion-holds.integration.spec.js#owes
    a cancelled notice
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/deletion/begin-destruction.integration.spec.js#owes
    an executing notice, so somebody is told the point of no return was passed
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#tells
    the people the plan owes a last notice to
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge-recovery.integration.spec.js#tells
    the people a deletion that failed was not completed
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#tells
    the staff list and the requester, and nobody else
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#sends
    the requested notice on the day of the request
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#sends
    both reminders, each on its own day, as the waiting period passes
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#slept
    until each notice was due rather than polling, and never for a fixed
    duration
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#ignores
    a notice whose schedule slot is already taken, so a re-run sends nothing
    twice
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/deletion/tenant-deletion-schedule.integration.spec.js#holds
    the deletion indefinitely when a notice could not be delivered, rather than
    destroying the tenant unannounced
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/deletion/begin-destruction.integration.spec.js#waits
    while a notice destruction waits for has not been sent
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/deletion/begin-destruction.integration.spec.js#names
    the notices it is waiting for
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#counts
    a suppressed notice as sent, which is the development and test path
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#still
    lists a failed notice, so a send that never worked never lets a tenant be
    deleted
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/persistence/tenant-deletion-requests.integration.spec.js#ignores
    a seven-day reminder that was never sent: only two kinds gate destruction
---

# Keep deletion decisions visible to staff: Acceptance Test Set

## Coverage

| Rule | Proved by |
|---|---|
| `BR-CAP-PFM-TNL-015-01` | `ATS-PFM-TNL-015-01` |
| `BR-CAP-PFM-TNL-015-02` | `ATS-PFM-TNL-015-02` |
| `BR-CAP-PFM-TNL-015-03` | `ATS-PFM-TNL-015-03` |
| `BR-CAP-PFM-TNL-015-04` | `ATS-PFM-TNL-015-04` |
| `BR-CAP-PFM-TNL-015-05` | `ATS-PFM-TNL-015-05` |
| `BR-CAP-PFM-TNL-015-07` | no scenario: `FND-PFM-TNL-014` |