Skip to main content

Two-Tier Tenancy Model

Orkestra operates on two distinct tiers of tenants. This distinction is load-bearing for every design decision — data isolation, RBAC scope, billing, and module activation all depend on which tier a request acts in.

Tier 1 — Internal tenants (operator side)​

The companies that run Orkestra. For each internal tenant the platform manages:

  • Internal users, roles, and RBAC
  • The internal company's own electronic invoicing (FatturaPA/SDI), billing, documents
  • Which modules / addons are enabled for that tenant
  • Operational admin (module config, audit logs, compliance evidence)

Tier 2 — External client tenants (customer side)​

External clients register on the platform, and each external client can itself be a multi-tenant organization (multiple sub-tenants / workspaces under one client). For each external client:

  • Client registration and onboarding
  • The client's own users, roles, sub-tenants

Per ADR-0006 (D1), this two-tier data model is core and survives intact in the tenant module (TenantKind = internal | external, orgs + memberships). The mechanism by which Tier-2 clients consume Tier-1 services — the catalog → subscribe → Stripe → entitlement flow, which lived in the subscriptions + payments modules — left with the addons. A fork that sells services to external clients rebuilds that consumption layer on top of the surviving data model.

Implications for contributors​

  • Every new endpoint must declare which tier it serves (internal operator, external client, or both) and enforce org-scoped RBAC accordingly.
  • Every new collection / table must carry a tenant scope (internal org ID or external client org ID) and be indexed / queried with that scope — never cross-tenant by default.
  • Module enable/disable is per internal tenant, but service consumption is gated per external client subscription. Do not conflate the two.