Portals, sub-accounts and nested organisations: the multi-tenant question for training providers

When a training provider wins a client who wants their own branded academy, the architecture of the platform underneath decides whether that is an afternoon of configuration or a six-week project. Three different things are sold as multi-tenancy: portals, sub-accounts, and genuinely nested organisations. Only the third gives a client their own domain, their own administrators, their own reporting, and a data boundary that still holds when a developer forgets a filter.

The distinction reads like vendor trivia until a client asks for something the model cannot express. Then it becomes a commercial problem, because what you can sell is bounded by what you can separate.

What a client actually asks for

Strip the requirements document down and four requests are left. They arrive in roughly this order, and almost every client paying you to train their people asks for them.

1. Their own domain. `learn.acmecorp.com`, not `yourcompany.lms-vendor.com/acme`. With a certificate that does not make the browser complain.
2. Their own administrators. Someone on the client side who can add users, publish a course and pull a report without emailing you first.
3. Their own reporting. Numbers about their people and nobody else's, in a shape they can put in front of their own board.
4. Their data separated from other clients' data. Usually asked as a security question, always the one that procurement escalates.

Each architecture answers some of these and fails at others. The failures are predictable once you know which model you are standing on.

Three architectures, three ceilings

The three models below are not a maturity ladder. They are different products for different buyers, and each one has a specific point where it stops.

Portals

A portal is a separate front door onto a shared pile of content and users. You define an audience — employees, partners, one client company — give it a URL and a theme, and assign people to it. Several corporate platforms are built around this shape; LearnUpon is the clearest example, with multi-portal delivery as the core of the product.

Portals answer the first ask well. A client gets a front door that looks like theirs, and learners who log in never see the other audiences. For a company training employees, partners and customers from one account, that is often the right amount of structure.

The list of portals is flat, and that is where it stops. A client with three regions and a group-level training director is not one portal, and it is not three unrelated ones either. Providers on a flat model end up encoding the missing hierarchy in names — `Acme`, `Acme - EMEA`, `Acme - APAC` — and then reassembling the group view by hand in a spreadsheet every quarter. Administrator roles have the same problem: rights are granted per portal, so the group director gets three grants that nobody remembers to revoke when a region closes.

Sub-accounts

Sub-accounts usually come from the billing system rather than the data model. One paying account owns some child accounts, normally one level deep, sharing a user table, a subscription and often a single domain with a path per child. TalentLMS is candid about this being a lighter separation than full multi-tenancy with per-tenant custom domains, and for a small team training staff that lightness is a feature, not a defect.

The question worth asking is where the boundary is enforced. If a sub-account is a column on a row, then separation is whatever the application code remembers to filter by.

-- A boundary that lives in application code
select * from enrolments where account_id = :current_account;

-- A boundary that lives in the database
create policy tenant_read on enrolments
  for select using (org_id = any (current_org_scope()));

The first query is correct right up until someone builds a new export endpoint and leaves out the `where` clause. The second stays correct anyway, because the database refuses to return the rows. That gap is what procurement is feeling for when it asks how client data is kept apart, even when it asks in the vocabulary of certifications and audits.

Nested organisations

In the third model the organisation is a first-class record, and an organisation can have a parent. Branding, domain, users, roles, content, enrolments and reporting all hang off it. Your training company is an organisation. Each client is an organisation inside yours. The client's regions are organisations inside theirs, as deep as their real structure goes.

Your training company              you administer everything below
├── Acme Corp                      learn.acmecorp.com
│   ├── Acme EMEA                  regional admin, EMEA data only
│   └── Acme APAC
├── Borden Group                   training.bordengroup.com
│   └── Borden Manufacturing
└── Public catalogue               open enrolments, your brand

Two things follow that a flat model cannot give you. The first is that a client's own shape is representable without naming conventions — you are not encoding hierarchy in strings. The second is scope: a role granted at a node applies to everything under that node. Acme's training director sees Acme and both regions. The EMEA manager sees EMEA. You see all of it. Nobody at Borden sees any of it, and none of that is a report anyone wrote by hand.

It also changes what offboarding means. When a client leaves a flat system, someone runs down a checklist of portals, users, groups and reports hoping the list is complete. When a client is a subtree, you delete the subtree, and everything that hung off it goes with it.

How each model answers the four asks

• Their own domain. Portals: usually yes, one per portal, sometimes at extra cost. Sub-accounts: often a path or a subdomain of the vendor's domain rather than the client's own. Nested organisations: a domain per organisation, at any depth, if the platform issues certificates automatically.
• Their own administrators. Portals: yes, but scoped to the one portal, so a group-level administrator needs a grant per portal. Sub-accounts: usually the parent's administrators with a filtered view. Nested organisations: an administrator at any node, with rights that cascade to everything under it.
• Their own reporting. Portals: per portal, with cross-portal roll-ups depending on the product. Sub-accounts: typically one report with a filter, which is fine until a client asks to see it themselves. Nested organisations: every node is a reporting scope, so the group view and the regional view are the same query at different heights.
• Their data separated. Portals and sub-accounts: as separated as the application code makes them. Nested organisations: as separated as the platform enforces below the application — ask, specifically, whether the rule sits in the database.

None of this makes portals wrong. It makes them a different product for a different buyer. The mistake is buying a portal model because the demo showed a logo swap, and discovering the ceiling on the day you sign a client who has regions.

Five questions to put to a vendor

1. Can an organisation contain another organisation, and how deep does that go?
2. If I grant someone an administrator role at one node, does it apply to everything below it, or do I grant it again at each level?
3. Is the tenant boundary enforced in the database or in the application code?
4. Can each client have their own domain and their own certificate, or only a subdirectory of yours?
5. When a client leaves, what exactly does removing them delete — and can you show me?

Ask for the answers in a shared document rather than on a call. The second question in particular tends to produce a demo of a screen rather than an answer, and the difference between the two is a year of manual grants.

Why the answer decides what you can sell

If your platform can only theme one front door, you are selling seats on your system. The client's staff log in to your brand, the client's training manager asks you for numbers, and every renewal is a conversation about your platform's cost per user.

If you can hand a client a domain, administrators, reporting and a boundary that survives a security review, you are selling them their own academy. That is a different contract. It renews differently, because by then the client has their own administrators with their own habits and their own content inside it, and it survives a change of buyer on their side.

The other half is operational. Providers who outgrow a flat model often end up running one installation per client. Moodle is explicit that multi-tenancy is not part of the core product — separating campuses or client organisations means Moodle Workplace, a partner contract, or parallel installations. Parallel installations mean parallel upgrades, parallel backups, parallel security patches and a reporting layer you rebuild outside the platform. It works while you have more staff than clients.

Where Lurno sits

Lurno is built on the third model. An organisation can contain sub-organisations, each with its own branding and its own custom domain with automatic TLS. Inside an organisation there is a second tree of branches, and a role granted at a branch cascades down it — which is the answer to the second vendor question above, and the reason a group training director is one grant rather than one per region.

The boundary is enforced in Postgres rather than in the application: 868 row-level security policies across 676 migrations, so a missing filter in a new endpoint returns nothing instead of returning someone else's learners. That is the claim worth checking with any vendor, ours included — the details are on the security page, and the branding and domain side is on white-label.

Two shapes this already runs, without naming anyone: a corporate academy running training for 15 client companies from one tenant, and a K-12 publisher running 114 schools on a single platform. Both are the same structure at different widths.

Two limits worth stating plainly, because they change the evaluation. Payments and checkout are in development — today a client is invoiced outside the platform, so if you need learners paying by card at the point of enrolment, that is a conversation rather than a feature. And partner sign-on (silent SSO) is available, but SAML and OIDC are on the roadmap and not shipped; if a client's IT department has already decided how their staff will authenticate, ask about that before anything else. The rest of the model for providers reselling training is set out on the training providers page.

The short version

Portals give a client a front door. Sub-accounts give a client a filtered view. Nested organisations give a client a boundary, and a boundary is the thing you can put a price on. Work out which one you are buying before a client asks you for the thing your model cannot say.