Multi-Client Functionality
The imc Learning Suite is a role-based learning management system where users are assigned to groups to provide privileges for functions and objects. The level above groups is Clients and all users must be assigned to at least one client where their master-client determines many important platform settings. This article will provide a detailed overview of multi-client use cases, functionality, and configuration possibilities. Being an extremely comprehensive Learning Management System with a large range of functions and advanced configuration; this article will only cover functions that are directly impacted by multi-client configuration.
What is Multi-Client?
A multi-client configuration essentially refers to using one Learning Suite instance to serve multiple customers or audiences through a logical separation; this is commonly referred to as ‘multi-tenancy’. With a multi-client configuration multiple customers (normally related) share the same database and content server. A logical separation is achieved through advanced multi-client configuration settings in many functions and the use of powerful access control list functionality (clearances). There are many imc customers with multi-client configured systems; mostly parent organisations with multiple subsidiaries or an association providing a branded LMS space to member organisations.
Multi-Client Benefits
The main benefit of a multi-client system is predominantly cost savings due to reduced architecture fees. There are further benefits including:
Shorter project implementation time for sub-clients if there is an existing system in place being extended;
Having separate designs, URLs, and public landing pages per client;
Reduced project costs, setup fees, and possibly licence fees;
Flexibility with multiple interfaces such as single sign-on;
Utilising pre-configured objects;
Sharing of learning content between clients; and
Ability to move users between related clients should users change organisation.
When to Use a Multi-Client Separation
Before proceeding with a logical separation it must first be determined if a multi-client configuration is really needed; this is because the configuration can be timely and is often not required. For example, a simple requirement of internal and external users can be achieved using separate groups. Below is a list of scenarios where a multi-client setup would be required:
Different user groups require different designs (colour schemes, logo etc.) as each client can support a single design;
Different user groups require different user profiles with different personal attributes;
Multiple SAML or OIDC authentication interfaces are required as each client can support only one of each interface;
A desire to restrict platform languages per geographic region in a system used in many countries;
Multiple URLs and public access pages are required; and
A need for different system wording to display for different groups.
Multi-Client Considerations
From a functional point of view, the bulk of functions and interfaces in the imc Learning Suite are designed to support client specific scenarios. This means that each client in a logical separated multi-client system can have a unique configuration setup and own interfaces to differentiate the experience from other clients; however, the larger the configuration requirements, the larger the effort meaning greater costs. There are some restrictions though with platform wide configuration settings such as SCIM API user provisioning and account registration messages where only one configuration is possible. The largest consideration for a logically separation is there needs to be a default client and system owner with full visibility; the latter would generally be responsible for customer side support requests and coordinating patch updates with the imc Support team.
Multi-Client User Experience
From a learner experience perspective there will be no real identifiable differences with a logically separated multi-client system compared with a stand alone single client system. The system would be specific to their organisation in terms of the skin design, platform wording, user profile fields, system emails, catalogue content, dashboard content, and news items. Even if a user was assigned to multiple clients there would still be a master-client that determines the default design and profile settings, but there could be additional catalogues and even dashboards depending on configuration.
In terms of the Administrator experience there are some important differences with a logically separated system. The first would be in many user related functions there is a ‘Client context’ selection field to select whether changes are to be ‘Global’ or client specific. Functions with the ‘Client context’ include ‘Users’, ‘User lists’, ‘Profiles’, and ‘Staff pool’. Super administrators or system administrators in the default system client will be able to configure changes for any client context including global, but administrators in sub-clients would only be able to configure changes for their own client.
The only functions not recommended to be accessible by administrators of sub-clients is the ‘Settings > Configuration’ manager as this contains hundreds of platform wide settings that can effect all clients. The settings here are recommended to be managed by imc, especially the ones relating to interfaces such as SAML, LDAP, SCIM, and csv batch imports. All other functions consider strong access right control with Clearances to determine which users, groups, or clients are able to access each object to varying levels.
Access Control List / Clearances
Access control is governed by the ‘Clearances’ function that regulates the level of access individual users, groups, and clients have to any object; whether it be learning content, training catalogues, report, dashboards, or users. Different types of objects contain varying clearance possibilities, but minimum available access rights on all objects would include Execute/View, Edit and Delete. In a logically separated multi-client environment the configuration of clearances, and especially default clearances, is paramount to a successful setup. Clearances can be granted automatically by configured business rules or granted manually by administrators when objects are created. In the administrative functions viewing or assigning access permissions to objects is possible via the ‘Clearance’ icon. When creating an object the creator receives full unrestricted clearance and when manually assigning clearances to other users the creator will only be able to select individual users and groups that they have clearance to view in the LMS.
Roles Concept
The imc Learning Suite is a role-based system where users are assigned to roles (represented by groups) that provide privileges to both functions and objects. To keep the navigation simple, a user that is assigned to more than just a learner role is able to toggle between roles by clicking the ‘Role switch’ icon. Any number of role-based groups can be configured with as little as one function to a system administrator group with access to all functions. When a user is assigned to multiple roles they receive the sum of all access rights their assigned groups have access rights and clearance to. With logically separated multi-client systems, the configuration of additional user groups or roles is very important to ensure a clear division of user assignment and access privileges. This allows the use of unique navigations for each client, automatic assignment of clearances to client administrators on objects or users created for that client.
What’s Involved in a Multi-Client Configuration?
A multi-client configuration can be relatively small for a basic scenario or quite large where there are complex requirements. The core division is largely achievable through Clearance functionality and business rules to determine which objects or users are visible in the system to whom and to what level. Then there are numerous functions that can be configured client-specific to create unique environment. Below are the areas to consider with a basic and advanced multi-client configuration:
Basic
Enabling ‘multi-client context’ functionality in ‘Configuration > Client’ function.
Creating the Client and configuring settings including the client sub-settings.
Creating Groups and defining access navigation and function privileges.
Defining default access rights for objects in the 'Configuration > Clearances' function.
Manually granting new admin groups clearances for ‘type’ objects (E.g. Course types, Media types).
Manually granting new admin groups clearances for other important objects (E.g. Course rooms, Cancellation reasons, panels etc.).
Configuring client specific personal attributes and user profiles (if required).
Creating business rules file in the Client function to assign users to groups and grant clearances on users.
Panel and dashboard (internal, external) creation.
Catalogue creation.
Creating new navigation points of dashboards and catalogue.
Updating navigation access to new dashboards and catalogues for new groups.
Advanced
New skin design for client.
Difference public URL requiring SSL certificate.
User imports (CSV, SCIM) - Possibly with SFTP setup.
Business unit import (XML or CSV).
Interfaces (SAML, OIDC, LDAP etc.).
User list updates.
System text updates.
Provider configuration and linking to client.
Branding enrolment messages and notifications.
Creation of enrolment message triggers.
Email sender whitelisting SMTP to relay.
Testing
With any logical multi-client separation, testing is a very important step to ensure that all objects have been properly configured in terms of assignment and access rights. Below is a list of some core tests that would need to be performed for a base configuration:
Is the client portal page accessible on the configured URL or parameter?
If an own domain is in use, is the SSL certificate correctly applied?
Is the correct dashboard and design displayed?
Is the system name (projectTitle) updated in the browser tab?
Are the desired login options enabled? E.g. Local login and/or SSO
If ‘Register’ is enabled, does account self-registration create the new user in the correct client and learner group?
Are account creation notifications sent?
If so, are the account creation notifications sent from the correct sender?
Are newly created users via backend assigned to the correct client and learner group?
Does the new administrator group have clearance on the new users?
Logging in with a learner account of the new client, does the:
Dashboard load correctly?
Catalogue display?
Navigation look correct?
Profile personal attributes look correct?
Logging is with an administrator account of the new client, does the:
Role change icon appear?
Navigation options available look correct?
Users menu show users assigned related to the new client?
Clearance enable editing the new users.
Organisation structure and groups menu display the new groups?
Groups allow the administrator to edit and assign users?
Course templates menu show Course types when ‘Create’?
Media menu show Media types when clicking ‘Create’?
Newly created objects automatically grant clearance to the admin group?
Content functions not show unintended content of other clients?
Reports menu in the ‘Admin’ category show reports?
Admin > Assignments > Catalogue menu show the correct catalogues?
Catalogue allow the administrator to assignment content and clearances?
Dashboard pages menu show the correct dashboards?
Dashboard pages menu allow the client dashboards to be edited?
The level of testing performed is very important and can take as long (if not longer) than the multi-client configuration itself.
Summary
It’s now hopefully clear what a logical multi-client separation is, when a multi-client configuration is actually needed, what configurations are required to perform a basic multi-client setup, and what the possibilities are for a more advanced setup. The configuration possibilities listed above are purely those where there is direct multi-client capability in the function or a configuration requirement. There are many further functional areas that can be further configured by the client administrators that have deliberately not been discussed in this document as they are considered general configurations. Whilst a multi-client setup is technically possible for customers to mostly configure, it is highly recommended to work with the imc Consulting team in such setups given the complexity and range of possibilities.