Skip to main content

Tenant Provisioning

Summary​

Platform contains an idempotent metadata orchestrator and an optional background capability that can provision an isolated tenant database. Source proves both implementations exist; production enablement and adoption of the optional model require confirmation.

Audience​

  • Platform administrators and implementation partners
  • Support, development, DevOps, architecture, and security teams

Purpose​

Provisioning coordinates the platform records needed to onboard a tenant while preserving progress, auditability, retries, and event publication.

Architecture​

Business concepts​

  • Idempotency — Implemented: the metadata orchestrator checks for existing records and resumes completed work instead of blindly duplicating it.
  • Stages and status — Implemented: requests carry overall status, current stage, progress, completed stages, failure details, and retry timing.
  • Feature, license, and branding setup — Implemented: the orchestrator establishes or reconciles platform-side records.
  • Event publication — Implemented foundation: lifecycle events are written through the platform outbox; successful provisioning emits a tenant-provisioned contract.
  • Admin bootstrap — Foundation: Platform records a login-pending request and emits an event. It does not create an Identity user itself.
  • Optional database-per-tenant worker — Foundation: background code can claim eligible requests, prepare a tenant data boundary, apply migrations, and seed baseline records.
  • Production adoption — Requires confirmation: source configuration capability does not prove that the optional worker is enabled or used in a production environment.

Technical implementation​

Validation checks source-confirmed input constraints and conflicts before provisioning. The synchronous orchestrator supports provision, retry, and resume operations and records each stage. The optional worker leases eligible work, records completion or failure, and uses bounded retry/dead-letter concepts without exposing internal schedules, database naming, SQL, credentials, or infrastructure identifiers.

Duplicate tenant identifiers are rejected during creation or validation. Repeating an accepted provisioning request is handled through idempotent record checks and tracked progress rather than by creating parallel tenant foundations.

Source References​

  • microservices/src/platform-service/Application/TenantProvisioningOrchestrator.cs
  • microservices/src/platform-service/Api/PlatformTenantOnboardingEndpoints.cs
  • microservices/src/platform-service/Provisioning/TenantProvisioningWorker.cs
  • microservices/src/platform-service/Provisioning/TenantDatabaseProvisioner.cs
  • microservices/src/platform-service/Provisioning/TenantProvisioningOptions.cs
  • microservices/src/platform-service/Domain/Entities/ProvisioningRequest.cs
  • microservices/src/contracts/Events/TenantProvisionedEvent.cs
  • microservices/src/shared-kernel/Outbox/

See Also​

Keywords​

  • Metadata provisioning
  • Provisioning stages
  • Admin bootstrap
  • Isolated tenant database

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-14
  • Review cycle: Quarterly