Sub-organisations, branches and groups — and when you need each

A sub-organisation is a full child organisation nested inside another, with its own people, programmes, roles, branding and domain. A branch is a tree inside a single organisation — campuses, departments, regions — where a role granted at a branch applies to everything below it. A group is the cohort, class or team that people are actually enrolled through. Almost every platform sells one or two of the three under the same word, and almost every buyer asks for all three without distinguishing them.

They are not alternatives. A working setup uses all three at once, at different heights: sub-organisations for boundaries, branches for scope, groups for enrolment. Putting a piece of your structure at the wrong height is not fatal, but it is expensive to undo, because by the time you notice, people have history attached to the thing you now want to move them out of.

• Sub-organisation — does this part of the structure need its own brand, its own domain, its own administrators, or its own boundary in somebody's security review? Then it is a sub-organisation.
• Branch — does this part exist so that a person can be put in charge of a slice of the organisation? Then it is a branch.
• Group — does this part exist so that a set of people can be enrolled, taught and marked together, between two dates? Then it is a group.

The order matters. A sub-organisation is the heaviest answer and the hardest to reverse, so it should be the one you have to argue for. A group is the lightest, and a surprising share of what people ask for in a requirements document turns out to be a group with an important-sounding name.

ORGANISATION  Northwind Academy               one tenant, one contract
 SUB-ORG      Acme Corp                       own domain, own admins, own boundary
  BRANCH      EMEA                            a role granted here reaches all below
   BRANCH     Dubai office
    GROUP     Compliance intake, September     40 people, one programme, two dates

Read top to bottom, each layer answers a different question. Who is separated from whom. Who is responsible for what. Who is learning this, together, now.

Sub-organisation: a boundary you could hand over

In a sub-organisation 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. A parent can see into its children; a child cannot see up or sideways. Nesting goes as deep as your real structure does — a group of schools, each school, and in some trusts a federation above the group.

That last point is the one worth pressing any vendor on, including us. If a tenant is a column on a row, separation is whatever the application code remembered to filter by, and it holds until the next feature ships. If the rule sits in the database, the query returns nothing when the filter is missing.

The weight of a sub-organisation is real. Each one is configured once: branding, a domain and its certificate, administrators, roles, retention and consent settings. In exchange you get something you can hand over. A sub-organisation has an owner who is not you, and offboarding is a subtree you delete rather than a checklist of users, groups, courses and reports that somebody hopes is complete.

Branch: where a grant stops

A branch is an operational node inside one organisation. Campuses, departments, faculties, regions, delivery centres, cost centres, franchise areas — whatever your organisation chart actually says. Branches share the organisation's brand, its domain, its users and its content library. What they carry is scope.

The cascade is the whole point. Give someone a role at the EMEA branch and it covers EMEA and everything under it, today and after you open two more offices. Without a cascading tree, the same person needs a grant per node, and the grants outlive the reason for them. Nobody remembers to revoke the Dubai grant when the Dubai office closes, because nobody has a list.

Depth is where branch trees go wrong. The tree should mirror the org chart, not the timetable. Every level you add is a decision a human makes each time a person joins, and a five-deep tree with one manager in it is administration with no reader. If nobody is ever going to be given a role at a level, that level is a report filter, not a branch.

Group: the unit people are enrolled through

A group is a set of people who learn something together. Class 4B. The September compliance intake. The graduate cohort. The project team doing the new-product training before launch. A group has a membership that changes, usually a programme attached, and an end.

Groups are where churn belongs, and that is the argument for keeping them separate from the other two. Membership changes weekly. Somebody joins late, somebody transfers, somebody repeats a module with the next intake. None of that should rewrite a person's permissions or move them between organisations. Moving a learner between groups is a small act; moving a learner between sub-organisations is a migration.

Three worked examples

A school group

A trust with two schools, or a publisher running 114 of them, has the same shape at different widths. Each school is a sub-organisation: it has a name parents recognise, a head who owns their own staff list, usually its own domain, and often its own inspection and its own funding agreement. The trust sits above them and can see down.

Inside a school, phases and departments are branches — the head of sciences is one grant that covers every science class in the school. Classes, form groups and sets are groups.

Riverside Trust                             the group
├── Riverside Primary       SUB-ORG         own domain, own head, own inspection
│   ├── Early years         BRANCH
│   └── Key stage 2         BRANCH
│       └── Class 4B        GROUP           28 pupils, one form tutor
└── Riverside High          SUB-ORG         own domain, own head
    ├── Sciences            BRANCH          head of department scoped here
    └── Humanities          BRANCH
        └── Year 10 history, set 2   GROUP

The trap here is year groups. Somebody wants attainment by year across the trust, so year groups get created as organisations, and now every pupil is in the wrong kind of container and every school's brand and domain settings have to be repeated per year. Year is an attribute of a group and a dimension in a report. It is not a tenant.

A corporate academy

Take a corporate academy running training for 15 client companies from one tenant. Each client company is a sub-organisation. It gets its own domain, its own administrators who can publish and pull reports without emailing the academy, its own branding, and a boundary that holds when the client's security team asks about the other 14.

Inside a client, business units and regions are branches, because the client's own training director needs one grant that covers all of them and a regional manager needs one that covers a slice. The September onboarding intake, the annual anti-bribery run, the twelve people doing the leadership programme — those are groups, and they are created and closed constantly.

The trap here is a sub-organisation per engagement. A client signs for three courses, so three organisations get created, each with its own branding to configure and its own administrators to invite, and then the client asks for one report across all three and nobody can produce it. One client, one sub-organisation. Three courses is three groups.

A training provider

A provider runs a mixture, and it is the mixture that makes the model earn its keep. There is a public catalogue with open enrolments under the provider's own brand. There are corporate contracts, each wanting an academy that looks like the client. There are accredited programmes with fixed cohorts, assessors and an awarding body that will ask for records.

Your training company                       everything below is yours to administer
├── Public catalogue        BRANCH          open enrolments, your own brand
│   └── Project management, Nov intake      GROUP
├── Acme Corp               SUB-ORG         learn.acme.com, Acme's own admins
│   ├── EMEA                BRANCH
│   └── Americas            BRANCH
└── Borden Group            SUB-ORG         training.bordengroup.com
    └── Borden Manufacturing    SUB-ORG     a subsidiary with its own brand

Two things to notice. The public catalogue is a branch, not a sub-organisation, because it is your brand, your domain and your staff — there is nothing to separate. And the third level is real: a client with subsidiaries that have their own identity is a normal case for a provider, and it is the case a one-level-deep sub-account model cannot express without naming conventions.

Four questions before you draw the tree

1. Which parts would a stranger's browser have to show a different brand and a different address for? Those are sub-organisations.
2. Which parts does a named person need to be put in charge of? Those are branches.
3. Which parts have a start date and an end date? Those are groups.
4. Which parts exist only because a report needs a filter? Those are none of the three.

The fourth question saves the most work. A great deal of structure gets built because somebody wants numbers cut a particular way, and structure is the most expensive possible way to get a filter. Reporting scope should follow the branch tree and the group, not the other way round.

How this works in Lurno

Lurno has all three as distinct primitives, which is why this post is worth the length. Sub-organisations nest arbitrarily, each with its own branding and its own custom domain with automatic TLS — the branding and domain side is set out on white-label. Inside an organisation there is a second, separate tree of branches, and a role granted at a branch cascades down it. Groups are the enrolment primitive, and they carry no permissions of their own.

The boundary is enforced in Postgres rather than in application code: separation enforced underneath the platform, so a query that forgets its filter returns nothing. That is the claim to check with any vendor — the detail is on the security page.

Two limits, stated plainly because they change how you plan a rollout. Accounts are created by invitation — self-serve signup and payments are in development, so a client organisation is set up and invoiced rather than buying itself. And partner sign-on (silent SSO) is available today, while SAML and OIDC are on the roadmap and not shipped; if a client's IT department has already decided how staff will authenticate, raise that early. The delivery model for providers reselling training is on the training providers page.

The short version

Sub-organisations separate. Branches scope. Groups enrol. When you are unsure which one a piece of your structure is, ask what breaks if you get it wrong: putting a boundary where a branch belonged costs you repeated configuration and a report you cannot run, and putting a branch where a boundary belonged costs you a conversation with somebody's security team. Draw the tree before you load the data, and make somebody defend every sub-organisation on the list.