An LMS for Qatar Business Groups: Separate Data, Consolidated Reports

Imagine a business group in Doha that moves its three companies, a hotel operator, a facilities services firm, and a retail chain, onto one set of LMS software. The first group report looks excellent: one completion rate for every employee in the group, produced in minutes. A week later, an HR officer at the retail company searches for a new joiner and finds herself scrolling through the overdue courses, assessment scores and refresher plans of employees at the group’s hotels. Nobody planned that. The platform was simply set up as one organization.

Business groups have good reasons to share LMS software: one catalog of common courses, one contract and one view of training across the group. But each company remains a separate employer, with its own staff, managers and data obligations. The real requirement is to keep each employer’s training data apart while still producing consolidated reports for the group.

This article sets out what HR, IT and procurement teams in Qatar should require from LMS software for that purpose, covering entities, permissions, group reports and shared content, and the tests that show whether a platform meets those requirements before you sign.

Why Group LMS Software Needs Separation and Consolidation

Two groups of users want different things from the same LMS software. Group learning and HR leaders want shared courses such as the code of conduct and information security, group-wide completion figures, and a fair comparison between companies. Each company wants its own employees, its own managers’ views, its own courses and confidence that sister companies cannot browse its records.

Configured as one flat organization, LMS software mixes employers’ data. Configured as separate installations, it pushes consolidation back into spreadsheets that someone rebuilds every month. The structure you need sits between the two: one learning management system, with the employing company built into every record, permission, and report.

Requirement 1: Model Each Employer as an Entity in the LMS Software

Every employee record in the LMS software should carry the employing entity as a mandatory field, fed from HR data rather than typed by hand. Where people work for one company but are employed by another, as with secondments or shared-services staff, record both the employing entity and the work assignment, and decide which one drives permissions and reports.

Ask each provider to demonstrate this in its LMS software, using your own entity structure:

• Each company set up as a separate entity, with its own administrators, local courses and certificate details.

• An employee transferring from one group company to another, and what happens to their training history.

• A new company joining the group, and how long it takes to add it without disturbing the others.

• A company leaving the group, and how its records are exported and removed.

Transfers deserve particular care. Decide whether the LMS software should move the history with the employee, keep it with the former employer, or copy it, and who may see it afterwards. Our guide to managing employee role changes in an Arabic LMS in Qatar covers what should happen to open assignments when people move.

These decisions also have a legal side. When Qatar’s Ministry of Transport and Communications released guidelines for the Personal Data Privacy Protection Law No. 13 of 2016, it urged regulated entities to position themselves according to their role as data controller or data processor. Ask your legal team how that applies to each employing company and to whichever group entity operates the LMS software, before you configure who can see what.

Requirement 2: Scope Permissions by Role and Entity

Most LMS software assigns permissions through roles, and that is a sound starting point. NIST’s glossary describes role-based access control as access control based on user roles, with role permissions that typically reflect what people need to perform defined functions. In a business group, a role alone is not enough: an HR administrator at the hotel company and one at the retail company have the same role but must see different people.

The missing piece is the entity. NIST also defines attribute-based access control as an approach in which access is mediated by attributes of the person requesting access and of the object being accessed. Applied to LMS software, the employing entity becomes an attribute on both the administrator and the learner record, so access follows the combination of role and employer. Ask providers how their platform achieves this; do not assume it does.

Write the result down as a permission matrix: roles in rows, entities and actions (view, assign, edit, export) in columns. Then test it in the LMS software sandbox with one test user per role:

• A company HR administrator searches for an employee of a sister company and gets no result.

• The same administrator opens the completion list of a shared group course and sees only their own employees.

• A line manager exports their team report, and the file contains no one from another entity.

• A scheduled report email goes only to recipients in the right entity.

• Every view and export of records is written to an audit log that group IT can review.

Shared courses are where LMS software most often lets mixing slip through, because one course record holds learners from every company. Keep group-wide administrator accounts to a minimum as well: every account that can see all entities is a standing exception to the matrix, so name its holders, review them each quarter, and make sure their activity appears in the audit log. Our guide to managing LMS permissions across company branches looks at scoping permissions inside a single company, which you will need within each entity as well.

Requirement 3: Consolidate Group Reports Without Exposing Records

Group leaders need consolidated figures from the LMS software, but rarely named records from every company. Agree on the level of detail first. Many group questions, such as completion of the code of conduct or overdue safety training by company, can be answered with counts and rates per entity. Named drill-down should be limited to the people with a clear need, recorded in the permission matrix.

Then test consolidated reporting in each LMS software sandbox against these checks:

• The group report total equals the sum of the entity reports for the same period.

• Completion and overdue mean the same thing in every entity, using the same course identifiers for shared courses.

• An employee who transferred mid-period is counted once, under the entity agreed in your rules.

• Very small teams are not shown in a way that reveals one person’s result.

• Group users can see entity totals without opening individual records unless the matrix allows it.

Counting once matters for courses that exist in two languages as well. If the same requirement appears as an Arabic and an English course, group totals in the LMS software will double unless the versions are linked, as explained in our guide to managing Arabic and English in one pathway.

Requirement 4: Share Content, Not Records

Shared content is one of the main reasons to choose a single LMS software platform, so define who owns it. Group-wide courses should be owned and updated centrally, assigned by each entity under its own rules, and recorded against each employer separately. Company-specific courses, such as the hotel’s food safety module, should stay within the entity that owns them. Check in the LMS software that an entity administrator cannot edit a shared course, and that a change to a shared course does not silently reset completions across every company.

A Hypothetical Example: Three Companies, One Platform

The following example is hypothetical and is included only to illustrate the method.

A Doha business group with a hotel operator, a facilities services firm, and a retail chain plans to replace three separate platforms with one. Its shared-services company will operate the LMS software. Before inviting proposals, group HR and IT write a permission matrix with six roles and three entities, list ten acceptance tests, and prepare test data for 90 fictitious employees, including two transfers and one secondee.

Both shortlisted LMS software platforms pass the basic entity tests. One, however, shows every learner in the completion list of a shared course to every company administrator. The other keeps lists separate, but its group report counts the two transferred employees in both entities. Procurement records each failure with screenshots, asks both providers for written fixes, and reruns the ten tests. The group then chooses the LMS software that passes all ten with the fewest manual workarounds, not the one with the more impressive group dashboard.

Put the Requirements into the Contract

Requirements that live only in a workshop are forgotten after go-live. Attach the permission matrix and the acceptance tests to the request for proposal and to the contract, so the chosen LMS software has to pass them at handover and again after every major update. Agree who reviews the LMS software audit log, how often, and what happens when an entity joins or leaves the group.

Summary

A business group can share one learning platform without mixing employers, but only if the LMS software is built around entities from the start: every record tied to its employer, permissions scoped by role and entity, group reports that consolidate figures without exposing records, and shared content owned centrally.

Write those requirements into a permission matrix and a set of acceptance tests, run them in a sandbox with realistic data, and keep them in the contract. That is how Qatar groups get consolidated reports from LMS software while each company’s employees stay in their own.

Click here if you want Skillup MENA to help you.