中文
devexamples
← Workflows

阅读中文版本

Multi-Tenant Onboarding Workflow

Provision a tenant with isolated data, scoped configuration, seeded defaults, and a verified access boundary so the first user lands in a correct, secure space.

intermediate~90 minmulti-tenantprovisioningsecurity

Objective

Create a new tenant end-to-end with isolation, configuration, and verification before any real user signs in.

Environment

  • Tenant provisioning automation
  • A verification script for isolation

Steps

1. Create the tenant record

Create the tenant record and its isolated storage or schema.

Expected state: The tenant has a dedicated namespace.

2. Apply scoped configuration and seed default

Apply scoped configuration and seed default data.

Expected state: The tenant starts with usable, correct defaults.

3. Provision the first admin identity

Provision the first admin identity and role bindings.

Expected state: An owner exists without an open sign-up.

4. Run isolation checks proving the tenant

Run isolation checks proving the tenant cannot see others.

Expected state: Access boundaries are verified before go-live.

Decision points

Schema per tenant or shared with a tenant column?

  • Schema per tenant
  • Shared table

Schema per tenant for strong isolation; shared tables for many small tenants where connection cost dominates.

Seed data by copy or by script?

  • Script
  • Copy from template

Script is auditable and versioned; template copy is fast but drifts.

Expected outcome

A tenant that is isolated, correctly configured, seeded, and owned by an admin, with isolation proven by automated checks.

Verification

Confirm the isolation test reads zero rows from other tenants and that the seeded data and configuration match the plan.

Cleanup

Record the tenant id, owner, and provisioning run in the registry.

Overview

Create a new tenant end-to-end with isolation, configuration, and verification before any real user signs in. Confirm the isolation test reads zero rows from other tenants and that the seeded data and configuration match the plan.

Steps

  1. Create the tenant record and its isolated storage or schema. Expected state: The tenant has a dedicated namespace.
  2. Apply scoped configuration and seed default data. Expected state: The tenant starts with usable, correct defaults.
  3. Provision the first admin identity and role bindings. Expected state: An owner exists without an open sign-up.
  4. Run isolation checks proving the tenant cannot see others. Expected state: Access boundaries are verified before go-live.
await provisioning.createTenant({ id, plan });
await provisioning.seed(tenantId, 'defaults');
await provisioning.bindOwner(tenantId, adminId);
await isolation.assertNoCrossTenantReads(tenantId);

Verification

  • A tenant that is isolated, correctly configured, seeded, and owned by an admin, with isolation proven by automated checks.

Decision points

  • Schema per tenant or shared with a tenant column? Options: Schema per tenant; Shared table. Recommended: Schema per tenant for strong isolation; shared tables for many small tenants where connection cost dominates.
  • Seed data by copy or by script? Options: Script; Copy from template. Recommended: Script is auditable and versioned; template copy is fast but drifts.