Skip to main content

Tenants

A tenant is one organisation's own space: its people, content, settings, colours and sign-up links. Nothing in one tenant is visible from another; the database enforces it on every row. A person can belong to several tenants, and a session works in one at a time (see Authentication).

  • Creating a tenant is a platform admin's act, and makes the creator an admin of it in the same step. Its code (capitals, numbers and underscores, at most 32) is fixed once created; renaming changes only the name. The new tenant gets its baseline configurations and the seeded surfaces.
  • The DEFAULT tenant is the shared library. Its atoms, sequences, journeys, surfaces, assets, task types and relationship kinds are readable from every tenant; a tenant's own record with the same code shadows the library's.
  • A tier records the level of the product a tenant is on. No operation is gated by it yet.
  • Deleting a tenant is a platform admin's act, and erases the people only it held (see Consent, access logging and erasure).

Default journeys​

A tenant's defaultJourneyIds are what every new participant starts on, however they join: a sign-up link or code, open sign-up, an invitation, an admin adding them, or their first sign-in through the tenant's own directory. Staff are never started on them.

  • Joining only adds. A participant already on one of these journeys is left where they are.
  • Only published journeys start; one since unpublished or archived is skipped, and the person joins without it.
  • The list is read at the moment someone joins, never again. To reach people already in, assign the journey to them.
  • One list per tenant. To give a cohort something the others don't get, branch on cohort in a default journey.

Tenant or cohort​

A cohort shares everything with its tenant (content, colours, tabs, admins, default journeys) and has its own sign-up code and picture. Anything that must differ in branding, configuration, administrators or tier needs its own tenant.