Tenants are where the actual data lives. This guide is for organization owners who need to create, rename, or delete tenants — the everyday admin tasks around an org's data workspaces.

Who can manage tenants

  • Org owners — full control over every tenant the org owns: create, rename, delete, transfer.
  • Org members — can only see and use tenants their roles grant access to; they cannot change tenant settings.
  • User-owned tenants — managed only by their owning user, from the user's own profile.

If you do not see the management actions described below, you are not an owner of the tenant's organization.

Creating a new tenant

From the organization page → Tenants tab → + New tenant:

  1. Name — what users will see in the tenant switcher. Acme Production, Acme Staging, etc.
  2. Default language — the canonical language for Localized String fields. Pick the language the data is mostly written in.
  3. Supported languages — every additional language the tenant should accept for Localized String values.
  4. (Optional) Copy structure from — pick an existing tenant to clone its schema assignments. See Promoting a schema for the deeper walkthrough.
  5. Save.

The new tenant appears in the tenant switcher for every org member who has access to it. Empty by default — no instances, no bookmarks, no dashboard widgets.

Renaming a tenant

Click the tenant row → Rename, type the new name, save. The change is immediate and visible to every member at their next page load. Internal IDs are unaffected.

A rename is a good way to mark a tenant's purpose changing — Acme Staging becoming Acme Sandbox once a real staging exists elsewhere.

Tenant settings

Each tenant has a small settings page where you can adjust:

  • Default language and supported languages — changing the default has implications. Existing Localized String values keep their per-language entries; the canonical fallback now points to the new language. Existing rows where the old default was the only value entered may render empty until you add a value in the new default.
  • Display name — the human-friendly name shown in the switcher.

Deleting a tenant

From the tenant row → Delete. Yellow asks for confirmation; deletion is soft — the tenant is marked deleted and hidden, but its data is retained for the org's retention window so it can be recovered if needed.

Before deleting, consider:

  • Is there a synchronisation job (see Copying data between tenants) that uses this tenant as a source or target? Stop those first.
  • Are there bookmarks or saved queries across the org pointing into this tenant? They become invalid.
  • Do any API keys target this tenant? Revoke them.

Hard-deletion (full purge) is performed by Yellow administrators on request, once the retention window expires.

Default tenants for users

Per-user defaults live on each user's profile (see Your profile and settings) — the organization itself does not set defaults globally. If a new hire should land on a specific tenant, ask them to mark it as default the first time they sign in.