White-label learning platforms: multi-tenancy explained

White-label describes how a platform looks: it carries the brand of whoever offers it, not the brand of the software maker. Learners see their academy’s logo, its colours, its typeface and its address in the browser. Ideally this applies not only to the interface but also to certificates, emails, exports and videos.

Multi-tenancy describes how a platform is built: one installation serves many organisations, and each sees only its own data. A tenant is a self-contained unit with its own accounts, courses, results and settings. Together, the two give you a platform that can serve many clients in their own brand without setting up a separate system for each.

The decisive question is: where is separation enforced? If only the interface filters, a single programming error on one page is enough for one tenant’s data to appear for another. Separation in the database itself is more robust. Every table carries the organisation’s identifier, and row-level rules ensure that a query returns only rows belonging to the caller’s own tenant.

Access that has to bypass these rules, for background jobs or the operator’s own administration, should be rare, justified and logged. Ask vendors specifically how they handle this and how they test it. A good answer describes a mechanism, not an intention.

Multi-tenancy is more than data separation. Every tenant has its own needs: a university needs exams and student administration, a mid-sized company only courses and records. A good platform therefore lets features be switched on and off per tenant, so that everyone sees exactly what they have booked and is not confused by menus full of other people’s features.

That includes custom roles and permissions, languages, domains, sign-in through the organisation’s identity system and templates for certificates and emails. The more of this a tenant can manage itself, the less it depends on the operator day to day.

Most tenants are well served by a shared installation. They benefit from shared updates and lower costs. For some organisations that is not enough, for example when internal policies require a separate database, a dedicated environment has been agreed contractually or particularly sensitive data is processed.

Academies and training providers that deliver courses to several corporate clients can give each client its own learning area in the client’s brand. Groups with subsidiaries separate data by company while still sharing common content. University alliances run one platform for several institutions. And software houses or consultancies offer learning under their own name without having to build a platform themselves.

Make sure the brand is right in the places you do not see straight away: on the certificate, on a credential’s verification page, in the exported video and in the sender address of the reminder email. A single foreign name in the wrong place undermines learners’ trust.

Universe is built for multi-tenancy: every table carries the organisation, and the database decides through row-level rules who sees which row. Each tenant gets its own brand, its own address and its own modules, and every feature can be switched per tenant. A course carries the brand of the organisation it names, in the player, in exports and in video. On request, a single switch turns the same software into a customer instance with a separate database.