IOMAD extends standard Moodle to support organizational learning in a multi-tenant environment, allowing multiple company tenants to operate within one platform while departments and branches can be structured within those tenants for management and reporting. Yet the complexity of tenancy combined with licensing introduces challenges as you scale: course visibility may bleed, permissions may get tangled, catalogues exposed across tenants and duplication becomes operational overhead. This article illustrates and explains major multi-tenancy and licensing types in IOMAD, identifies issues and limitations we have encountered (such as the need to duplicate courses for each branch), and presents recommended fixes to address them.
I recently migrated my site to Mindfield from another host, and the experience couldn’t have been better. Mindfield kept working until they were certain that my site was operating as well as it was before, and they even helped clean up a few issues to improve my site’s performance – issues my prior host never mentioned. I also found Mindfield’s communication to be excellent. Before the migration, they prepared me for what to expect, and during the migration they kept me well-informed. No small feat considering that changing hosts is inherently stressful! They also provided clear and concise explanations when required. I’d highly recommend Mindfield if you’re looking for an IT consultant, developer, or host.
Jim Benedek
Owner, Student First Media Inc.
review Source: Google Reviews
Outline
Why Multi-Tenancy and Licensing Issues Matter
Multi-tenancy provides powerful tenant separation, but misconfiguration leads to unpredictable results. These problems matter because they directly impact platform stability, maintenance workload, security, reporting accuracy, and user experience.
- Visibility and Permission Risks
Incorrect catalogue rules or license configurations can cause users from one branch or company to see courses intended for another. This is one of the most common issues reported in IOMAD environments.
- Course Duplication and Maintenance Burden
One of the biggest issues in IOMAD is the assumption that licenses require separate course copies for each branch. This results in heavy maintenance overhead.
- Reporting and Data Leakage
When roles or licenses bypass tenant boundaries, managers may see data from other tenants, undermining trust in reports.
- Broken Learning Paths and Enrollment Drift
When users move between tenants, their training plans and enrollment logic may not update automatically.
- Licensing Constraints Can Force Inefficiencies
Licenses in IOMAD exist inside a tenant. This creates false assumptions that each tenant needs its own course version. Without correct use of cohorts and catalogue filtering, administrators are forced into unnecessary duplication.
IOMAD is widely used across industries that require centralized training with strong organizational separation. Common examples include professional associations, franchise networks, healthcare and clinical training providers, financial services organizations, retail and hospitality chains, manufacturing and logistics companies, government or regulatory bodies, and corporate learning academies supporting multiple subsidiaries or regions. In all of these environments, maintaining clear tenant boundaries while avoiding unnecessary duplication is critical for scale.
Understanding these risks helps organizations avoid major maintenance and governance problems as they scale.
Multi-Tenancy Types in IOMAD and Licensing Models
Before configuring IOMAD, it is important to distinguish between a tenant and the organizational structure that exists inside a tenant.
In IOMAD, a company represents a tenant. Departments and sub-departments organize users within that company, while parent and child companies allow organizations to create multiple related tenants when stronger separation is required.
A practical IOMAD hierarchy can therefore look like:
IOMAD Site → Parent Company Tenant → Child Company Tenant → Departments → Sub-departments
The correct level depends on how much separation each part of the organization requires.
1. Company Tenant
A company is the primary tenant level in IOMAD. Each company can have its own users, management structure, branding, course access, reporting, and configuration.
Use a Company Tenant When
Create a separate company tenant when an organization, customer, subsidiary, or business unit requires meaningful separation such as:
- Separate branding
- Separate company administrators
- Independent user management
- Separate catalogue or course access
- Tenant-specific reporting
- Separate licensing or training administration
For example, if a training provider serves five unrelated corporate customers, each customer would normally be created as its own company tenant rather than as a department of the training provider.
2. Parent and Child Company Tenants
IOMAD also supports parent and child companies. This is useful when separate business entities need their own tenant environments but still belong to a larger organizational structure.
A parent company can sit above multiple child company tenants, allowing the organization to preserve separation while supporting centralized oversight.
Use Parent and Child Companies When
This model works well for:
- Corporate groups with multiple subsidiaries
- Multi-brand organizations
- Franchise structures requiring stronger separation
- Regional companies with independent administration
- Training resellers managing their own customers
For example:
Northstar Manufacturing Group
→ Northstar Canada — Child Company Tenant
→ Northstar USA — Child Company Tenant
Each regional company can operate as a separate tenant while remaining connected to the parent organizational structure.
3. Departments Within a Tenant
Departments are not separate tenants. They are used to represent the internal organizational hierarchy inside a company tenant.
Departments can also contain sub-departments, allowing the structure to follow an organization’s reporting hierarchy.
For example:
Northstar Canada — Company Tenant
→ Toronto
→ Operations
→ HR
→ Sales
→ Vancouver
→ Operations
→ HR
→ Sales
Use Departments When
Use departments for:
- Branches
- Locations
- Internal divisions
- Teams
- Functional departments
- Management and reporting hierarchies
Departments are the better choice when users belong to the same tenant but need to be segmented for management, reporting, training assignment, or organizational purposes.
4. Shared Courses Across Tenants
Shared courses are not another tenant type. They are an access and course-management model used when multiple company tenants need the same training content.
Instead of creating a separate copy of the same course for every tenant, organizations can maintain a master course and control access using appropriate company assignments, licensing, enrolment, and catalogue rules.
This reduces course duplication while allowing tenant-specific user management and reporting.
Use Shared Courses When
Use this model when:
- Multiple tenants require identical training
- Course content is centrally maintained
- Tenant-specific course copies are not required
- Administrators want to reduce update and maintenance overhead
The key is separating course ownership and maintenance from tenant access and reporting.
Why These Issues Occur: Root Cause Analysis
Across IOMAD deployments, the same root causes appear repeatedly:
- Misunderstood Licensing Model (“Donuts and Desks”): Licenses exist inside tenants, not globally. This concept, commonly explained in IOMAD as Donuts and Desks, describes how access (the donut) is separated from organizational structure (the desk). Misunderstanding this relationship leads directly to unnecessary course duplication and incorrect catalogue exposure.
For a detailed explanation, refer to the official IOMAD documentation on Donuts and Desks.
Why licenses are like donuts and desks… – IOMAD - Poor Category Architecture: Global categories cause cross-tenant visibility.
- Manual Enrollment Drift: Users manually enrolled into courses bypass tenant rules.
- Department or Tenant Moves Without Plan Rebuilds: Training plans remain attached to old structures.
- Excessive Use of Blanket Licenses: Blanket licenses ignore tenant boundaries when configured incorrectly.
- Reactive Duplication of Courses: Instead of using cohorts and license rules, administrators duplicate everything to solve access issues quickly.
Once these root causes are addressed, architecture becomes far more stable and scalable.
Solutions and Recommendations
Short Term Fixes
These are immediate actions that resolve common multi-tenant issues:
- Audit All Licenses
Ensure licenses do not span tenants unintentionally.
- Reduce Duplicate Courses
Consolidate duplicates into one master version.
- Tighten Role Permissions
Ensure managers do not have global view capabilities.
- Fix Catalogue Structure
Make sure course categories mirror tenant boundaries.
- Validate All Enrollment Methods
Check that:
-
- self enrollment is tenant restricted
- training plans reflect current users
- no manual enrolments break license logic
Long Term Solutions
These actions ensure system health as the organization grows.
- Establish Governance Rules
Define clear procedures for tenant creation, license assignment, course sharing, and reporting. Consistent governance prevents ad-hoc decisions that lead to duplication and access issues.
- Use a Master Template Course Model
Maintain a single authoritative course version wherever possible. Control tenant access through cohorts, catalogue rules, and license constraints instead of duplicating content.
- Automate User Assignment
Use SSO, HR feeds, or identity integrations to align users with the correct tenants and departments automatically. Automation reduces enrollment drift and manual errors.
- Set Up Standardized Update Procedures
Centralize course updates and configuration changes to avoid version drift across tenants. Standard procedures ensure updates remain consistent and auditable.
- Train Administrators on Licensing and Tenancy Concepts
Ensure administrators understand tenant boundaries, license behavior, and catalogue visibility rules. Shared understanding prevents configuration mistakes as teams grow.
- Retire Redundant or Legacy Course Copies
Regularly audit and remove outdated or duplicated courses. Reducing clutter lowers maintenance overhead and improves reporting accuracy.
- Design and Enforce a Clear Organizational Hierarchy
Before creating a new tenant, determine what level of the organization actually requires independent administration and separation.
A simple rule is:
- Company tenant: Use when the entity requires its own users, administrators, branding, reporting, catalogue, or training administration.
- Child company tenant: Use when an independently managed entity still needs to sit beneath a larger parent organization.
- Department: Use for branches, locations, divisions, or teams that belong inside the same tenant and primarily require organizational, management, or reporting separation.
- Sub-department: Use for additional hierarchy within a department.
For example, a manufacturing group should not automatically create one tenant for every factory. If all factories belong to the same company and share the same branding and administration, the company can remain one tenant while each factory is represented as a department. If a regional subsidiary operates independently and requires separate administration, branding, or reporting, it can instead be configured as a child company tenant.
The decision should therefore be based on the level at which true organizational separation is required, rather than simply creating a tenant for every level of the org chart.
Related Articles
If you are working with IOMAD multi-tenancy, licensing models, or complex enterprise learning structures, the following articles offer deeper insights into performance, catalogue control, role configuration, and long term platform stability. Each resource provides practical guidance that builds on the concepts discussed here and helps you create a reliable and scalable IOMAD ecosystem.
- Top Moodle Themes for Moodle IOMAD
- Managing Moodle Upgrades with IOMAD
- How to Migrate from Moodle to IOMAD
- How to Enable Multi-Tenancy in Moodle
- Migrating Moodle from Single to Multi-Tenancy
- Moodle Multi-Tenancy Overview
- Moodle Multi-Tenancy Plugin Overview
Turning Multi-Tenancy Challenges into Scalable Solutions
Designing and maintaining a stable multi-tenant IOMAD environment requires deep understanding of Moodle core architecture, IOMAD’s tenant extensions, licensing behavior, catalogue rules, course access logic, and enrollment pathways. Many of the most common issues—such as cross-tenant visibility, unnecessary course duplication, blanket license leakage, broken training plans, and managers seeing users outside their tenant—occur not because the platform lacks capability, but because its multi-tenancy structure has been configured without a clear architectural plan. Experienced Moodle and IOMAD experts know how to set up clean tenant boundaries, optimize catalogue visibility, design proper course structures, and implement license rules that reduce maintenance instead of increasing it.
By working with specialists, organizations gain a reliable foundation that scales smoothly as more branches, companies, departments, or training programs come online. Experts help eliminate duplicated courses, strengthen reporting isolation, automate user assignment via SSO or HR feeds, design upgrade-safe configurations, and introduce governance models that keep the system future ready. Instead of reacting to issues after they surface, a seasoned IOMAD expert builds a long term roadmap, ensuring your LMS remains efficient, secure, and easy for administrators and learners to navigate.
