---
id: ATS-PFM-TNL-002
scope: CAP-PFM-TNL-002
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-002-01
    title: Dependencies determine construction order
    level: unit
    proves:
      - BR-CAP-PFM-TNL-002-01
    preconditions: Participant declarations include their prerequisites.
    steps: Derive the plan and step catalog.
    expected: >-
      The workspace comes first and participants appear once before readiness
      and activation.
    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/provisioning/provision-tenant-workflow.spec.js#runs
        the tenant row before anything that depends on it
      - >-
        services-platform:modules/tenants/tests/unit/services/provisioning/provision-tenant-workflow.spec.js#names
        every planned participant exactly once
      - >-
        services-platform:modules/tenants/tests/unit/services/provisioning/provision-tenant-workflow.spec.js#has
        one step per planned participant, then the readiness check and the
        activation
      - >-
        services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#provisions
        all seven of CRM’s participants, the tasks, activities and duplicates
        participants after the entities they depend on
    provenance: test
    source: >-
      services-platform:modules/tenants/tests/unit/services/provisioning/provision-tenant-workflow.spec.js#runs
      the tenant row before anything that depends on it
  - id: ATS-PFM-TNL-002-02
    title: Live declaration drift stops execution
    level: api
    proves:
      - BR-CAP-PFM-TNL-002-02
    preconditions: Live descriptions differ from the static participant order.
    steps: Start the lifecycle plan.
    expected: >-
      The refusal reports planned and current participants before their work
      runs.
    negative: true
    data_needs: >-
      Use the workspace, caller and collaborator fixtures declared by the bound
      tests.
    bound_to:
      - >-
        services-platform:modules/tenants/tests/unit/services/provisioning/provision-tenant-workflow.spec.js#refuses
        a run whose participants are not the ones it was planned for, naming
        both plans
      - >-
        services-platform:modules/tenants/tests/unit/services/lifecycle/remote-participants.spec.js#plans
        the live manifests, so normalised, in exactly the order the static
        copies plan (what the publish step compares)
      - >-
        services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#refuses
        the purge as planned for other participants rather than skipping one
    provenance: test
    source: >-
      services-platform:modules/tenants/tests/unit/services/provisioning/provision-tenant-workflow.spec.js#refuses
      a run whose participants are not the ones it was planned for, naming both
      plans
  - id: ATS-PFM-TNL-002-03
    title: Enablement controls remote construction
    level: api
    proves:
      - BR-CAP-PFM-TNL-002-03
    preconditions: Fixtures include enabled remote participants and a disabled application.
    steps: Provision under each registry configuration.
    expected: >-
      Enabled participants are invoked and the disabled application receives no
      description or work call.
    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/provisioning/provision-tenant.integration.spec.js#asks
        the other macroservice to provision each of its participants, for the
        tenant being provisioned
      - >-
        services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#neither
        describes nor asks Accounting while a registry that switches
        Accounting’s participants off is in force
    provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#asks
      the other macroservice to provision each of its participants, for the
      tenant being provisioned
  - id: ATS-PFM-TNL-002-04
    title: Readiness retains a missing-resource failure
    level: api
    proves:
      - BR-CAP-PFM-TNL-002-04
    preconditions: A participant cannot account for a required resource.
    steps: Run construction through readiness.
    expected: The missing resource is reported and the workspace stays closed.
    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/provisioning/provision-tenant.integration.spec.js#asks
        every participant to confirm what it made before the tenant is opened
      - >-
        services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#leaves
        the tenant where an operator can see it, and does not open it
    provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#asks
      every participant to confirm what it made before the tenant is opened
  - id: ATS-PFM-TNL-002-05
    title: Activation retains its first opening
    level: api
    proves:
      - BR-CAP-PFM-TNL-002-05
    preconditions: All construction participants report readiness.
    steps: Activate the workspace and repeat activation.
    expected: >-
      Active lifecycle uses the requested mode and the recorded activation time
      remains stable.
    negative: false
    data_needs: >-
      Use the workspace, caller and collaborator fixtures declared by the bound
      tests.
    bound_to:
      - >-
        services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#leaves
        the tenant usable once the job has run
      - >-
        services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#records
        when the tenant became usable
      - >-
        services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#shows
        one step per participant, then the readiness check and the activation
    provenance: test
    source: >-
      services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#leaves
      the tenant usable once the job has run
  - id: ATS-PFM-TNL-002-06
    title: Retry omits completed construction
    level: api
    proves:
      - BR-CAP-PFM-TNL-002-06
    preconditions: An earlier attempt stopped after partial completion.
    steps: Run a replacement attempt.
    expected: >-
      Outstanding resources are supplied without repeating completed participant
      work.
    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/provisioning/provision-tenant.integration.spec.js#does
        the missing work and not the finished work when it is provisioned again
      - >-
        services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#does
        not repeat work the other macroservice completed before it lost the
        answer
    provenance: test
    source: >-
      services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#does
      the missing work and not the finished work when it is provisioned again
  - id: ATS-PFM-TNL-002-07
    title: Construction progress satisfies its journey assertion
    level: api
    proves:
      - AS-JNY-PFM-TNL-001-02
    preconditions: The provisioning journey’s fixture has a successful build.
    steps: Inspect the resulting build snapshot.
    expected: 'Participant, readiness and activation steps are present and completed.'
    negative: false
    data_needs: >-
      Use the workspace, caller and collaborator fixtures declared by the bound
      tests.
    bound_to:
      - >-
        services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#shows
        one step per participant, then the readiness check and the activation
      - >-
        services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#says
        the provisioning succeeded
    provenance: test
    source: >-
      services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#shows
      one step per participant, then the readiness check and the activation
evidence:
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/unit/services/provisioning/provision-tenant-workflow.spec.js#runs
    the tenant row before anything that depends on it
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/unit/services/provisioning/provision-tenant-workflow.spec.js#names
    every planned participant exactly once
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/unit/services/provisioning/provision-tenant-workflow.spec.js#has
    one step per planned participant, then the readiness check and the
    activation
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#provisions
    all seven of CRM’s participants, the tasks, activities and duplicates
    participants after the entities they depend on
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/unit/services/provisioning/provision-tenant-workflow.spec.js#refuses
    a run whose participants are not the ones it was planned for, naming both
    plans
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/unit/services/lifecycle/remote-participants.spec.js#plans
    the live manifests, so normalised, in exactly the order the static copies
    plan (what the publish step compares)
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/deletion/tenant-purge.integration.spec.js#refuses
    the purge as planned for other participants rather than skipping one
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#asks
    the other macroservice to provision each of its participants, for the tenant
    being provisioned
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#neither
    describes nor asks Accounting while a registry that switches Accounting’s
    participants off is in force
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#asks
    every participant to confirm what it made before the tenant is opened
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#leaves
    the tenant where an operator can see it, and does not open it
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#leaves
    the tenant usable once the job has run
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#records
    when the tenant became usable
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#shows
    one step per participant, then the readiness check and the activation
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#does
    the missing work and not the finished work when it is provisioned again
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/integration/services/provisioning/provision-tenant.integration.spec.js#does
    not repeat work the other macroservice completed before it lost the answer
  - >-
    Inspected source:
    services-platform:modules/tenants/tests/e2e/tenant-provisioning.e2e.spec.js#says
    the provisioning succeeded
---

# Open a workspace after its applications are ready: Acceptance Test Set

## Coverage

| Rule | Proved by |
|---|---|
| `BR-CAP-PFM-TNL-002-01` | `ATS-PFM-TNL-002-01` |
| `BR-CAP-PFM-TNL-002-02` | `ATS-PFM-TNL-002-02` |
| `BR-CAP-PFM-TNL-002-03` | `ATS-PFM-TNL-002-03` |
| `BR-CAP-PFM-TNL-002-04` | `ATS-PFM-TNL-002-04` |
| `BR-CAP-PFM-TNL-002-05` | `ATS-PFM-TNL-002-05` |
| `BR-CAP-PFM-TNL-002-06` | `ATS-PFM-TNL-002-06` |

| `BR-CAP-PFM-TNL-002-08` | no scenario: `FND-PFM-TNL-030` |