One LMS for multiple companies or brands: what does ‘multi-tenancy’ mean?
A group of companies, a franchise network or a training provider serving multiple clients may wish to operate a single LMS whilst offering each organisation its own environment. At first glance, it might seem sufficient to create several groups, add different logos and assign an administrator to each group. In practice, however, it depends on just how deeply the separation between individual organisations actually extends.
This is where the concept of multitenancy comes into play. In a learning management system, it refers to a method of supporting multiple organisational environments within a single platform. However, its specific implementation varies between products. The term itself cannot therefore replace a demonstration of how it works and how data is handled.
Groups, branches and standalone environments have different capabilities
A group is often used primarily for assigning courses or filtering reports. A branch can add its own catalogue and branding. A tenant usually represents a broader organisational unit, but even here it is necessary to verify the actual level of isolation. The terminology used by individual suppliers is not a uniform technical guarantee.
Ask whether an administrator from one company can view another’s accounts, search for its staff, or open a direct link to their content. It is not just the list of menu items that matters. Restrictions must also apply when exporting data, via the API, in discussions and in related reports.
User segregation starts with permissions
It may be appropriate for a central operator to manage the entire system. A local administrator should have a precisely defined scope. For example, they need to be able to add people within their own company, but should not be able to change the login configuration for other organisations.
Request a demonstration with two test administrators. Each represents a different company and has their own access rights. Observe what happens during searches, bulk imports and when attempting to assign a user to another organisation’s course. Such a scenario will highlight differences that are not apparent from a central administrator’s presentation.
Shared content can be both an advantage and a source of surprises
A single shared course across organisations saves work when making updates. At the same time, it is important to know whether students will be able to see each other in the list of participants, in discussions or when marking assignments. Shared content and shared communication are not automatically the same thing.
The Totara documentation, for example, describes different behaviours depending on whether tenant isolation is enabled. This illustrates well why it makes sense to enquire about the specific mode. For your solution, ask for an explanation of what can be shared securely, what requires a copy of the course, and how changes are reflected in individual environments.
A custom brand needs more than just a logo
If each company is to present itself independently, check the domain, login page, colours, emails and documents displayed. Support contact details and links in announcements are also important. Otherwise, a shared platform may only appear independent when first opened, whilst subsequent communications display the central operator’s brand.
Check who edits the individual elements. A local administrator may be authorised to make changes to content, but branding may remain the responsibility of head office. This need not be a problem, provided the model is clear from the outset and complies with your rules.
A single person may belong to multiple organisations
A practical test involves an external trainer, auditor or staff member who works across several companies within a group. Do they need a single account with environment switching, or several separate profiles? How will they know which organisation they are currently working for? And where will their results be visible?
Moving between companies is equally important. Ask to be shown what happens to learning history, assigned courses and access rights. Creating a copy of an account may result in duplication, whilst simply changing the user’s affiliation may unexpectedly open or close access to content. Rules should be based on the system’s data model, not on manual improvisation by an administrator.
Shared reports require a clear scope
Head office may want a summary for the entire group, whilst individual companies should only see their own results. Ask whether the system can do both without the need for additional table merging, and whether the same restrictions apply to scheduled exports.
Also check the integrations. Can each tenant have its own user source, identity provider or different organisational structure mapping? If all companies use a single employee identifier solely within their own database, the migration must also recognise organisational affiliation. Otherwise, account conflicts may arise.
What to request in the demo and in the proposal
Prepare a simple model of two companies sharing a course and one external trainer. Ask the supplier to demonstrate:
- Separate account management and data visibility.
- The difference between shared and proprietary content.
- Moving a user between organisations and the impact on their history.
- A summary report for head office and a restricted report for the local administrator.
The quotation must clearly state the price for additional environments, the scope of their customisation, and the procedure for terminating a tenant. Also ask whether data from a single organisation can be exported separately. Terminating a contract with one client should not affect the data of all others.
Multitenancy can significantly simplify the operation of multiple learning portals. However, it delivers the greatest value where there are clearly defined boundaries between centralised administration and the autonomy of individual organisations. When making your selection in the LMS Catalogue, therefore, treat this requirement as a separate scenario to be demonstrated.
