Provisioning pipeline surface map

Walk the onboarding code path end-to-end and enumerate every surface that changes state during provisioning or deprovisioning. Per the AWS Well-Architected SaaS Lens (docs.aws.amazon.com/wellarchitected/latest/saas-lens/tenant-isolation.html (opens in new window)), isolation must be established at every layer of the stack independently:

Per the Microsoft Multitenant Architecture Center (learn.microsoft.com/en-us/azure/architecture/guide/multitenant/considerations/tenant-life-cycle (opens in new window)), onboarding must account for data residency, compliance tier, billing model, and disaster-recovery SLOs, each of which can gate provisioning steps. Capture which conditions gate each surface - a compliance-gated provisioning step needs its own test branch.

Per the Microsoft resource organisation guidance (learn.microsoft.com/en-us/azure/architecture/guide/multitenant/approaches/resource-organization (opens in new window)), quota and subscription limits must be modelled per tenant at provisioning time. Record the expected default quota values - they are assertions, not implementation details.

Provisioning test scenarios per surface

For each surface from the surface map, identify the scenarios that must hold.

Account creation

• Tenant record persists with a non-null unique identifier after a successful provisioning call.
• Provisioning a second tenant with the same email or slug returns an error (no silent duplication).
• A provisioning call that fails mid-flow leaves no partial record (atomicity).

Isolation at creation (no cross-tenant bleed)

Per the Microsoft tenancy models guidance (learn.microsoft.com/en-us/azure/architecture/guide/multitenant/considerations/tenancy-models (opens in new window)), isolation must hold from the first request a tenant makes, not only after steady-state data accumulates. Test cases:

• Immediately after Tenant B is provisioned, a call authenticated as Tenant A cannot enumerate Tenant B's resources (list endpoint returns 0 items for A).
• Tenant B's provisioned schema or row-level security policy is in place before the first application-level write is accepted.
• No existing tenant's data becomes visible to the new tenant through shared infrastructure (cache warm-up, search index bootstrap, etc.).

Default resource quotas

Per the Microsoft consumption measurement guidance (learn.microsoft.com/en-us/azure/architecture/guide/multitenant/considerations/measure-consumption (opens in new window)), per-tenant consumption limits should be tracked from provisioning. Test cases:

• A new tenant's quota record exists immediately after provisioning and matches the expected default values for the tenant's pricing tier.
• Attempting an action that exceeds the default quota (e.g., creating one more resource than the limit allows) returns a quota-exceeded error, not a generic error or a silent failure.
• Upgrading a tenant's tier updates the quota record (verify the seeded default and the upgrade delta separately).

Billing record linkage

Per the Microsoft tenant lifecycle guidance (learn.microsoft.com/en-us/azure/architecture/guide/multitenant/considerations/tenant-life-cycle (opens in new window)), billing linkage is a first-class onboarding concern. Test cases:

• A billing record (subscription, customer ID, or metering entry) exists and references the tenant's canonical identifier within the same provisioning transaction.
• A provisioning call with an invalid payment method does not create a half-provisioned tenant.
• The billing record's tier matches the plan chosen at signup.

Seed and default data

• Feature flags for the tenant's tier are present with correct default values.
• Default roles (e.g., owner, member, viewer) exist and are assigned to the provisioning user.
• Template or onboarding data (welcome project, sample records) is scoped exclusively to the new tenant - it does not appear in any other tenant's list endpoints.

Idempotent re-provisioning

An idempotent provisioning call is one that produces the same final state regardless of how many times it is invoked. Test cases:

• Calling the provisioning endpoint a second time with the same input returns a success response (or an explicit "already exists" response) without creating duplicate records.
• All constraint-unique fields (quota row, billing record, identity binding) remain singular after two provisioning calls.
• A re-provisioning call after a partial failure completes successfully without manual cleanup.

Teardown and offboarding

Per the Microsoft tenant lifecycle guidance (learn.microsoft.com/en-us/azure/architecture/guide/multitenant/considerations/tenant-life-cycle (opens in new window)), offboarding must define a retention period and support re-onboarding during that window. Test cases:

• After offboarding, the tenant's application data (records, files, jobs) is not accessible through any API endpoint.
• After offboarding, no row for the tenant exists in quota, billing, or identity tables (or rows are flagged deleted and excluded from active queries).
• Re-onboarding the same tenant during the retention period succeeds without data loss if re-onboarding is a supported operation.
• After the retention period expires (simulate with a fixed past timestamp), a hard-delete job removes all remaining rows; assert count = 0 across all tenant-bearing tables.

Provisioning test suite skeleton examples

Concrete skeletons for the emitted suite. Pick the framework from the selection table in SKILL.md; the pytest example below maps one-to-one to the scenarios in provisioning-test-scenarios.md (opens in new window).

Example skeleton (pytest)

import pytest

class TestTenantProvisioning:
    """Provisioning lifecycle tests - distinct from runtime isolation battery."""

    def test_account_creation_stores_tenant_record(
        self, provisioning_client, pricing_tier
    ):
        response = provisioning_client.post(
            "/api/tenants/",
            data={"slug": "acme", "plan": pricing_tier.id, "owner_email": "owner@acme.com"}
        )
        assert response.status_code == 201
        assert response.json()["id"] is not None

    def test_isolation_new_tenant_invisible_to_existing_tenant_immediately(
        self, client, existing_tenant_user, new_tenant
    ):
        # New tenant was just provisioned; existing tenant must not see it
        client.force_login(existing_tenant_user)
        response = client.get("/api/workspaces/")
        ids = {w["id"] for w in response.json()["results"]}
        assert new_tenant.id not in ids

    def test_quota_default_matches_tier_on_creation(
        self, new_tenant, pricing_tier
    ):
        from quotas.models import TenantQuota
        quota = TenantQuota.objects.get(tenant=new_tenant)
        assert quota.max_users == pricing_tier.default_max_users
        assert quota.max_storage_gb == pricing_tier.default_max_storage_gb

    def test_billing_record_linked_on_creation(
        self, new_tenant, billing_stub
    ):
        assert billing_stub.was_called_for(new_tenant.id), (
            "Billing provider must be notified during provisioning"
        )
        record = billing_stub.get_record(new_tenant.id)
        assert record["plan"] == new_tenant.plan

    def test_seed_data_scoped_to_new_tenant_only(
        self, client, existing_tenant_user, new_tenant
    ):
        # Existing tenant must not see new tenant's seed data in shared endpoints
        client.force_login(existing_tenant_user)
        response = client.get("/api/projects/")
        tenant_ids = {p["tenant_id"] for p in response.json()["results"]}
        assert str(new_tenant.id) not in tenant_ids

    def test_provisioning_idempotent_no_duplicate_quota_row(
        self, provisioning_client, new_tenant, pricing_tier
    ):
        # Call provisioning a second time with the same input
        provisioning_client.post(
            "/api/tenants/",
            data={"slug": new_tenant.slug, "plan": pricing_tier.id,
                  "owner_email": "owner@acme.com"}
        )
        from quotas.models import TenantQuota
        count = TenantQuota.objects.filter(tenant=new_tenant).count()
        assert count == 1, "Idempotent re-provisioning must not create duplicate quota rows"

    def test_offboarding_deletes_application_data(
        self, admin_client, offboarded_tenant
    ):
        admin_client.delete(f"/api/tenants/{offboarded_tenant.id}/")
        response = admin_client.get(f"/api/tenants/{offboarded_tenant.id}/projects/")
        assert response.status_code == 404

Example: idempotency via SQL assertion (language-agnostic)

-- After two provisioning calls for the same tenant slug:
SELECT count(*) FROM tenant_quotas WHERE tenant_id = '<new_tenant_uuid>';
-- Expected: 1 (not 2)

SELECT count(*) FROM billing_subscriptions WHERE tenant_id = '<new_tenant_uuid>';
-- Expected: 1 (not 2)