Skip to main content
Version: 2.5

Tenant management and sandboxes

A tenant has its own database, Elasticsearch indexes and DMS files. Tenants share the installed backend and frontend version. The same mechanism supports organizations, configuration sandboxes and isolated E2E, regression or load-test environments.

Enabling the feature​

Tenant management is disabled by default. The installation administrator must enable tsm.multitenant.management.enabled=true and configure the prepared URL pool in the backend. The UI menu and direct route require the separate tenantManagementEnabled=true UI parameter; its default is false. Enable both together after backend rollout. The login tenant selector is controlled independently by showTenant, which also defaults to false. Use the boolean true for UI flags; string values do not enable them.

Before enabling the feature, prepare DNS, ingress and TLS for every pool host and Redis for allocation locks. An unassigned pool URL returns 404. Enabling management replaces the legacy tenant registry CRUD/export endpoints and synchronous provisioning with the managed API and asynchronous Jobs; migrate consumers before switching it on.

Administrator workflow​

  1. Sign in as an administrator in the default tenant. Management is denied in every other tenant, including for users with Um.Tenant privileges.
  2. Open User management → Tenant management, load the available sources and explicitly select sourceTenant. Choose a creation profile when configured; remote sources require an explicit profile and must be allowed by it. Create an owned target with a unique code, name, purpose and optional lifetime. Sandbox lifetime defaults to seven days; test environments default to one day; organizations default to unlimited.
  3. Wait for the provisioning Job to finish. The list shows its status and the assigned prepared URL. Failed allocations remain visible for diagnosis and cleanup.
  4. Open the ready sandbox and change forms, processes, scripts, registers and other configuration. Prepare any business test data separately.
  5. Export the current configuration with tsm CLI into a feature branch. Review the Git diff and create an MR. ChangeSets are optional. After approval, import the reviewed configuration artifact into the destination tenant.
  6. Extend the lifetime or delete the sandbox. Expired tenants remain available with a warning during the configured grace period (three days by default), then a Job removes their resources. Tenant codes are never reused; URLs can be reassigned.

Creating a sandbox does not launch a separate application binary from a feature branch. Application code follows the usual application build and deployment process.

Copy scope and permissions​

Provisioning uses the published tsm-database-copy artifact and the approved copy-profile whitelist. The default profile copies configuration, registers, users (including password hashes), roles and privileges from the explicitly selected sourceTenant. Every tenant has its own users. Copying provisions a fresh owned target database and recreates the supported schema, including the excluded runtime tables, which remain empty. Only whitelisted rows are transferred; this is not a full database clone or a copy into an arbitrary populated target. Business data, running processes, history, sessions, refresh tokens and API keys are excluded. Runtime credentials are not copied; configure them separately for the target. CLI can align configuration afterward. Keep the source unchanged during copying when a reproducible baseline is required.

Standard privileges Um.Tenant.View, Um.Tenant.Add, Um.Tenant.Edit and Um.Tenant.Delete control administration in the default tenant only. The backend checks this restriction independently of the UI. A copied administrator in the target can use its own tenant but cannot access tenant management.

Installation guide and implementation reference​

Publish this guide after tsm-infra !1595 and its coordinated tenant changes have been merged and deployed. The release-branch link below is available only after that merge. Deploy the backend before enabling the UI parameter and verify routing on REF before the main installation.

The canonical technical guide lives with the implementation: Správa tenantů — TSM-2567. It defines the URL pool, routing and token validation, shared service identities, Redis and Job coordination, copy limitations, DMS paths and verification commands. Customer DNS/proxy/ingress implementations may differ; provisioning is implemented in tSM services.