Skip to main content

Tenants and Multi-Tenancy

The Raytio Platform is multi-tenant: a single deployment hosts many independent organisations side by side. A tenant is the isolation boundary that keeps each organisation's data, users, and configuration separate from every other tenant on the platform.

What a tenant represents​

A tenant is an isolated organisational boundary within the platform. Each tenant has its own:

  • Users and directory entries
  • Configuration parameters and settings
  • Reference data, menus, labels, and other Foundation content
  • Domain data (customers, work items, documents, and so on)

From the perspective of users signed in to a tenant, the platform behaves as if their tenant were the only one that exists. Activity in one tenant is never visible to another.

Tenant attributes​

Each tenant carries a small set of identifying attributes:

AttributePurpose
NameDisplay name of the organisation
DescriptionFree-text description of the tenant
Domain prefixShort, unique identifier used to route external traffic and identify the tenant publicly

The domain prefix is the most important attribute for integration: it is the stable, human-readable identifier that external systems and inbound URLs use to determine which tenant a request belongs to.

How tenant isolation works​

Every piece of data in the platform is scoped to a single tenant. When a user signs in, the platform establishes their tenant context and uses it on every subsequent operation to filter what they can see and change.

This isolation is automatic and unconditional:

  • Records created by a user are associated with that user's tenant.
  • Queries return only records that belong to the current tenant.
  • Cross-tenant references are not permitted — a record in one tenant cannot directly link to a record in another.

Because isolation is enforced by the platform itself rather than by individual features, every module inherits it without needing its own implementation. Tenant boundaries apply equally to user-facing screens, scheduled jobs, integrations, and reports.

How tenants relate to the rest of the platform​

Tenants sit at the root of nearly every other concept in the platform:

  • Users belong to a tenant. A user account exists within exactly one tenant and can only act within that tenant's data.
  • Parameters are tenant-scoped — each tenant configures its own settings without affecting others.
  • Reference data, menus, labels, jobs, documents, and notifications are all tenant-scoped. The same lookup code or menu code can exist independently in two different tenants with different content.
  • Permissions and access control operate within a tenant. Roles, groups, and direct grants apply to the records of one tenant only.

Reference data such as countries and currencies may use standard codes, but the records themselves are still tenant-scoped. Each tenant owns its own reference data configuration.

The public tenant domain lookup​

External systems need a way to identify which tenant they are interacting with before a user has signed in — for example, when displaying a tenant-branded login page, when receiving an inbound webhook, or when resolving a tenant-specific public URL.

The platform exposes a limited, public lookup that maps a domain prefix to the matching tenant's name and identifier. This lookup:

  • Returns only the minimum information required to identify the tenant (typically the name and domain prefix).
  • Does not expose any tenant data, user information, or configuration.
  • Is available without authentication so that external systems and pre-login flows can use it.

Once a tenant has been identified by its domain prefix, all subsequent requests are routed into that tenant's context, and normal tenant isolation applies.