One platform, configured five ways.
A corporate academy, a school group, a training provider, a university, a software company teaching its customers. Same build, same capabilities. What changes is the words, the shape and which modules are switched on.
Five configurations, not five products
Lurno is sold as one platform, not as five editions. A corporate academy, a school group, a training provider, a university department and a software company teaching its customers all run the same build: the same programs, the same 19 question types, the same rubric grading, the same certificates, the same audit log. What differs is configuration — what a sub-organisation stands for, what the interface calls a learner, how deep the branch tree goes under it, which modules are on, and who holds which role. The six pages below describe those six configurations. Nothing named on one is absent from another.
- Sub-organisation
- A nested organisation inside your tenant, with its own logo, palette, domain, administrators and members. It is the slot each audience fills differently: a client company for a corporate academy, a school for a publisher, a customer account for a software company, a faculty for a university. Programs are authored once and shared into it from the parent; its data stays kept separate underneath the platform underneath the platform itself.
There are no editions because the hard parts are the same everywhere. A bank training its staff and a publisher running 114 schools both need a role that stops a regional manager reading another region's results, a grade that means the same thing in a board pack as it did in the grading queue, and a certificate an outsider can check. Build that once and the rest is vocabulary, structure and modules.
So pick the closest fit rather than the exact one. The platform overview covers the capabilities themselves, and security covers how a single tenant keeps 114 schools apart.
Find the one closest to yours
The same platform from one buyer's side of the table: the structure, the roles, the parts that matter at that scale.
What the five share, and what they don't
The spine underneath every configuration
One tenant, nested organisations, and a branch tree inside each one — campus, faculty, region, department. A role granted at a branch cascades to every branch beneath it, so a campus administrator sees their campus and nothing above it. One permission catalogue governs a school group and a software company the same way.
- Roles granted at eight scopes: platform, organisation, sub-organisation, branch, program, cohort, course, group
- Separation enforced underneath the platform, not remembered by the screens on top
- One audit log that cannot be quietly edited, the same in every configuration
Five things you set, and nothing else
The difference between a corporate configuration and a school one is five settings. None is a code branch, a plugin or a separate deployment.
- Vocabulary. The glossary catalogue holds the words the interface uses. Editable terms are overridden per organisation, singular and plural, in each product language: learner becomes student, delegate or employee.
- Shape. What a sub-organisation stands for, and how deep the branch tree under it goes.
- Modules. Reporting is enabled per organisation. A group that only wants delivery never opens the grading queue.
- Roles. Which custom roles exist, and at which scope each one is granted.
- Brand. Logo, palette and domain per organisation, TLS issued automatically. A sub-organisation inherits its parent's brand until it sets its own.
Scale is a real difference, not a marketing one
One department and 114 schools are the same platform at different settings, and it would be dishonest to say the experience is identical. At one organisation most of the structure is invisible: make a program, invite people, issue certificates, never open the branch editor. At 114 the structure is the job — who administers which school, which programs are shared down, which reports stop where. Only one of those needs a week of setup, and we would rather say so now than on the third call.
Plans and member capsFive decisions, answered three ways
Every configuration answers the same five questions. These are the typical answers, not fixed ones — you can set them differently.
| Capability | Corporate academy | School group | Customer education |
|---|---|---|---|
| What a sub-organisation holds | A client company | A school | A customer account |
| What the branch tree is for | Region, department, team | Campus, year group, subject | Product line or region |
| What a learner is called | Employee or delegate | Student | Customer |
| How people arrive | Partner sign-on from the company portal, or an invitation | Invited in bulk by each school | Sign-on handed over from your own app |
| Modules usually switched on | Reporting, certificates, staff wellbeing | Guardians, competencies, certificates | Authoring, assessments, certificates |
Accounts are created by invitation in all three: self-serve signup and checkout are in development, so every configuration starts with a demo.
If you are more than one of these
Most institutions of any size are. A publisher that also sells corporate training, a university with a commercial arm, a training provider whose largest client wants its own branded portal — none of these needs two contracts.
One tenant holds organisations of different shapes at once, each with its own vocabulary, brand, domain and administrators. A program authored in the library is shared into whichever needs it, and the grading queue stays one queue. Read the page nearest your largest segment.
Before you pick a page
Bring the shape you actually run
Schools, client companies, faculties, franchises. We map it onto one tenant on the call, and say plainly what does not fit.