Tenants
A tenant is an isolated environment in which your data lives. Every instance you create — every customer, invoice, ticket, or whatever your models describe — belongs to exactly one tenant. Tenants give you separate worlds: production data, a staging copy, a personal sandbox, a customer's dedicated workspace — each one independent.
Why tenants exist
The metadata side of Yellow (schemas, models, properties) is designed to be shared and reused. The data side, however, must be kept apart. Tenants are the boundary:
- Isolation — instances in one tenant are invisible from another. Two tenants can have the same schema with completely different rows.
- Environments — keep a "production" tenant alongside a "staging" or "development" tenant that mirrors its structure but holds throwaway data.
- Per-customer workspaces — for products that serve multiple customers, each customer can have their own tenant under the same organization.
- Personal scratchpad — every user can have their own private tenant for experimentation.
Ownership
Every tenant is owned by either a user or an organization:
- User-owned tenant — created from the user menu → New Tenant. Only that user can access it. Useful for personal projects, experiments, or learning.
- Organization-owned tenant — created from the organization's Tenants page. Any owner member of the organization can manage it, and the organization's members can access it through their roles.
The ownership type is chosen at creation time and stays with the tenant. You can have many tenants of either type at once.
What a tenant contains
Inside a tenant you can find:
- Instances — the actual data rows for every model your schemas define.
- Files attached to instances — contracts, exports, images, anything you upload alongside a row.
- Tenant-scoped configuration — bookmarks, dashboard widgets, recent activity, and other user-specific state are stored per tenant so each environment keeps its own context.
Schemas and models themselves are not stored inside a tenant — they live one level up and can be reused across multiple tenants. This is why you can promote a schema from a sandbox to production: the structure travels with the schema, only the data stays tenant-local.
Switching between tenants
When you sign in, Yellow offers the tenants you have access to. The currently active one is shown:
- In the window title on desktop (e.g. Yellow · Acme Production).
- In the user menu, where you can pick Switch to this tenant to jump to another.
- As your default tenant under user settings — the one Yellow opens automatically next time.
Switching tenants is a re-authentication step: your session token is rebound to the new tenant, and all subsequent gRPC calls return only data from that tenant.
Cross-tenant resources
A few things deliberately cross the tenant boundary. They are admin-controlled and managed via specific capabilities:
- Cross-tenant files — system-wide files (for example, the help articles you are reading right now) shared by every tenant.
- Schema and tenant synchronisation wizards — operations available from the organization screen that copy schemas, or instance data with an optional cutoff date, from a source tenant to a target tenant. They are useful for promoting changes from a staging environment to production.
Without these explicit operations, the wall between tenants is complete.
Managing tenants
From the organization → Tenants screen you can:
- Create a new tenant under the organization.
- Rename a tenant by clicking its name.
- Delete a tenant (soft-delete; confirmation required).
- Synchronise schemas or data into another tenant.
For user-owned tenants, the same options live under the user menu.