--- id: CON-PFM-TNL-002 name: Provisioning feature: FEAT-PFM-TNL-01 product_area: platform module: tenant-lifecycle revision: 2 status: draft product_intent: confirmed implementation_evidence: observed source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 definition: >- Provisioning records a workspace request and runs the durable construction work needed before opening it. owned_by: MOD-PFM-TNL synonyms: - provisioning run - provisioning job - new workspace request not_to_be_confused_with: - existing-workspace initialization - later portal sign-in setup facets: - name: Submission meaning: >- A request identity makes repeated submission return the same result. A different request still cannot claim an existing or retired identifier. used_for: Recognizing repeats of the original request. - name: Plan and steps meaning: >- Enabled participants and their dependencies establish the work order. Comparing live and planned participant order detects registration changes before execution. used_for: Inspecting planned construction and progress. - name: Requested mode meaning: >- The request chooses live or implementation standing for activation, with implementation as the default. used_for: Choosing the business mode at opening. - name: First administrator meaning: >- A newly created customer can name a person for the customer-level Administrator invitation. Compatible existing invitations are adopted; unusable authority stops that step. used_for: Establishing the new customer’s initial access. - name: Sender setup meaning: >- Domain or address identities are established without waiting for DNS verification. Shared sending remains available while the requested identity is pending. used_for: Preparing association mail while verification remains pending. - name: Portal interest meaning: >- The recorded request reserves information for later portal work rather than promising a pool at construction time. used_for: Retaining information for future onboarding. - name: Outcome reporting meaning: >- The requester notice and operations alert let staff learn the result without continuously watching. Their failures have separate handling from construction. used_for: Reporting results outside continuous job inspection. - name: Retry lineage meaning: >- A new attempt refers to its failed predecessor and retains completed work, making recovery inspectable. used_for: Explaining the work retained by recovery. relationships: - to: CON-PFM-TNL-001 statement: Construction changes the workspace’s lifecycle when it opens or fails. provenance: observed source: >- services-platform:modules/tenants/services/persistence/tenants.ts:activateProvisionedTenant - to: CON-PFM-TNL-003 statement: Participants build and account for the resources in the provisioning plan. provenance: observed source: >- services-platform:modules/tenants/services/provisioning/provision-tenant-operations.ts lifecycle: - state: submitted meaning: The request and workspace are recorded before execution begins. how_it_changes: Execution starts or reconciliation settles the attempt. - state: running meaning: Participants are constructing the planned resources. how_it_changes: 'Readiness and activation succeed, or the attempt fails.' - state: succeeded meaning: The job has opened the workspace. how_it_changes: The completed attempt has no further transition. - state: failed meaning: The attempt stopped with partial construction retained. how_it_changes: Retry creates a separate attempt linked to this one. acted_on_by: - CAP-PFM-TNL-001 - CAP-PFM-TNL-002 - CAP-PFM-TNL-003 - CAP-PFM-TNL-004 visible_to: - ACT-PFM-004 - ACT-PFM-039 - ACT-PFM-012 evidence: - >- Inspected source: services-platform:modules/tenants/services/persistence/tenants.ts:activateProvisionedTenant - >- Inspected source: services-platform:modules/tenants/services/provisioning/provision-tenant-operations.ts supersedes: [] intent_sources: - >- services-platform:docs/tenants/tenant-lifecycle-plan.md#§4 (approved 2026-10-09) --- # Provisioning ## What It Is Provisioning is the accountable construction of a requested customer workspace. Staff provide its identity and customer relationship, then Rhythm records a durable job to build the application resources it needs. The workspace exists during construction but remains closed to ordinary customer work. Readiness separates a successful request from a usable result. The job gives staff a continuing reference for the work. Its steps represent participant construction, readiness and activation. A submission identity links repeated copies of the same request to that recorded result. Retry has its own identity and lineage, preserving the distinction between the original attempt and the work needed to finish it. ## What It Is Not Provisioning does not import the customer’s business records. Those arrive during a later loading period. It also differs from initialization, which supplies missing resources or defaults to an existing workspace. Portal onboarding builds member sign-in infrastructure later; a provisioning request can record portal interest without constructing that infrastructure. An accepted request is not evidence that construction has completed. Similarly, an outcome notice describes the job’s result but does not itself authorize customer access. ## How It Is Used A Rhythm administrator submits the workspace details and can inspect progress through the provisioning snapshot. The job asks application participants to build in dependency order, then checks what each participant created. A missing resource or protocol refusal leaves an explanation for staff and keeps the workspace closed. Failure preserves partial construction. Staff correct the cause and retry rather than ask the system to remove everything already built. The replacement attempt carries completed steps. An unwanted failed workspace instead follows deliberate deletion. Reconciliation and repair address attempts that never started or left the workspace behind their settled job state. ## Its Facets **Submission.** A request identity makes repeated submission return the same result. A different request still cannot claim an existing or retired identifier. **Plan and steps.** Enabled participants and their dependencies establish the work order. Comparing live and planned participant order detects registration changes before execution. **Requested mode.** The request chooses live or implementation standing for activation, with implementation as the default. **First administrator.** A newly created customer can name a person for the customer-level Administrator invitation. Compatible existing invitations are adopted; unusable authority stops that step. **Sender setup.** Domain or address identities are established without waiting for DNS verification. Shared sending remains available while the requested identity is pending. **Portal interest.** The recorded request reserves information for later portal work rather than promising a pool at construction time. **Outcome reporting.** The requester notice and operations alert let staff learn the result without continuously watching. Their failures have separate handling from construction. **Retry lineage.** A new attempt refers to its failed predecessor and retains completed work, making recovery inspectable. ## How It Relates Provisioning moves workspace lifecycle toward active or failed construction. Participants own the resources they build and the ledgers for their defaults. The job engine owns durable execution and shared job inspection. Workspace administration owns ordinary customer and workspace fields. Deletion supplies the exit for a failed build staff choose not to finish. ## What It Could Become The product should make activation housekeeping and its differing failure boundaries explicit. Planned cloning and extended portal-domain setup also need settled contracts before staff can rely on them. None of those extensions changes the existing distinction between requesting a workspace, completing its build and loading its customer records.