Skip to content
PRESHaiPRESHaiPRESHos Platform

New-tenant checklist

From “customer says yes” to “tenant ran its first governed session,” using the real surfaces. Check each box in order.

Phases run in this order: Create tenant in /admin/tenants, provision-tenant workflow, poll provisioning and the readiness gate, invite the owner on the tenant hostname, owner Day-0 (/preparing to /onboarding), verify the first session, hand off to steady state.

New tenant path: create tenant, provision, invite owner, preparing, onboarding, first session

Phase 1: Create tenant (/admin/tenants)

Section titled “Phase 1: Create tenant (/admin/tenants)”

Requires PRESH org-1 membership and platform_ops in org 1. API calls require org_id=1.

  • Kind: Customer selected
  • Org-1 CRM company and owner contact selected or created. The API requires org_id=1 and derives the owner email server-side (never hand-supply it)
  • Display name set (recognized organization name, becomes org-name)
  • Slug chosen. presh is reserved, pick anything else; short, recognizable, collision-checked
  • Hostname: enter e.g. acme.preshos.com, or leave blank to default to <slug>.preshos.com
  • Intended first workload and connector needs recorded as requests (code is not connected, never promised as live)
Admin tenants registry used when creating a tenant

Phase 2: Provision (provision-tenant Inngest workflow)

Section titled “Phase 2: Provision (provision-tenant Inngest workflow)”

Creation launches the durable provision-tenant Inngest workflow. Poll GET /api/v1/admin/tenants/[id]/provisioning plus evaluateTenantReadiness. Do not guess, poll.

Steps include (in workflow terms):

  • Registry, branding, hostname, config, RBAC
  • mint_workos_org (tenant identity minted in WorkOS)
  • link_registry, attach_domains
  • vault_placeholders (Tenant Vault grant slots ready)
  • ai_gateway_key (token-gated/overridable: may be skipped without blocking core-ready; never work around the gate itself)
  • verify_defaults
  • seed_default_agents
  • seed_owner / send_invite
  • converge_post_owner
  • vercel_alias (required for core-ready). Needs VERCEL_ARCHER_TOKEN and VERCEL_TENANT_PROJECT_ID (env-var names; values live in secret management, never here). Without the alias the tenant is not core-ready. The owner invite may still go out first (see Phase 4): invite can precede alias completion.

Phase 3: Readiness gate

Section titled “Phase 3: Readiness gate”
  • evaluateTenantReadiness passes; provisioning endpoint shows the tenant core-ready
  • Hostname serves the right deployment (alias verified after any redeploy)
  • At least one Agent Environment exists or is explicitly scheduled pre-invite. Never invite into a tenant with no path to first session.
  • Fresh-identity check: sign-in works, onboarding loads, Settings reachable

Phase 4: Owner invite to Day-0

Section titled “Phase 4: Owner invite to Day-0”

The invite may go out before vercel_alias completes. Invite status and alias status are separate. An invited owner can sign in, but stays on /preparing until the tenant is core-ready (which includes vercel_alias); the wizard waits on readiness.

  • Owner accepts the invite on the tenant hostname (not canonical; the invite is hostname-bound)
  • Owner sees /preparing until core-ready (which includes vercel_alias), then /onboarding/* (org-name, domain, branding, members, connect; org-name required, rest deferrable)
  • Owner reaches the dashboard; org identity confirmed in Settings

Customer-side companion: Day-0. Wizard code lives under app/(onboarding)/onboarding; preparing at /preparing; customer APIs under /api/v1/orgs/[id]/*.

Phase 5: First-value verification

Section titled “Phase 5: First-value verification”
  • Owner signed in at the correct hostname
  • One governed session run to a recorded outcome in an appropriate environment
  • At least one approval decision observed (or a clear reason none fired)
  • Record retrievable under the right org scope

Phase 6: Handoff

Section titled “Phase 6: Handoff”
  • Partner admins: enroll PRESHai internal emails via /admin/tenants/[id] Members. They then reach the tenant through My tenants (/my-tenants). Review posture at handoff (keep only what the operating model needs).
  • Object defaults: publish from the org-1 Object Manager via /api/v1/admin/object-defaults/*. Preview, then apply. Never apply unpreviewed.
  • Admin knows the Tenant admins section, member invites, and the connector/environment request path
  • Tenant tracked (hostname, org, phase, open requests); open items ticketed with owners, none verbal

Hostname baseline: wildcard *.preshos.com, WorkOS redirect https://*.preshos.com/callback, NEXT_PUBLIC_APP_URL=https://preshos.com.