Multi-tenant Moodle environments require a structured way to manage users across different organizations. Standard Moodle is designed around a single institution, but many organizations need to serve multiple companies while keeping data separate and secure. IOMAD extends Moodle by introducing a hierarchy of companies, departments, and roles, allowing administrators to manage thousands of users across multiple tenants without losing control or visibility. This article explains how user management works in IOMAD, how companies and departments interact, how roles are assigned, and how experienced administrators maintain stable multi-tenant environments.
Working with Mindfield is a life changing experience. From Product knowledge to technical expertise the team has gone above and beyond the call of duty more times then I can count.
Greg Shorland
Funeral Learning Hub
Outline
Companies, Departments, and Roles in IOMAD
IOMAD organizes users through a structured hierarchy consisting of companies, departments, and roles. Together these components determine what users can access and what administrators can manage.
Companies
Companies are the highest level container in IOMAD. Every user belongs to at least one company, and companies function as independent tenants within the same Moodle installation.
Companies determine:
-
Which courses users can access
-
Which reports administrators can see
-
Which dashboards are available
-
Which licenses apply
-
Which departments users belong to
Company administrators manage users within their own company, while site administrators manage the entire system.
Companies provide data separation so that organizations cannot see each other’s users or reports.
Users can belong to multiple companies, but this should be used carefully because it can complicate reporting and permissions.
Departments
Departments organize users inside a company.
Typical department structures include:
-
Regions
-
Offices
-
Business units
-
Teams
-
Certification groups
Departments can be nested to create a hierarchy.
Example structure:
Company: Example Training Ltd
Departments:
-
North America
-
Canada
-
USA
-
-
Europe
-
UK
-
Germany
-
Departments help administrators:
-
Assign courses to groups
-
Run reports
-
Allocate licenses
-
Delegate management responsibilities
Departments make large companies manageable without creating multiple tenants.
Roles
Roles define what users are allowed to do within the system.
IOMAD uses standard Moodle roles along with company-level roles.
Common roles include:
Site Administrator
Can manage the entire Moodle system including all companies and global settings.
Company Administrator
Can:
-
Manage company users
-
Assign courses
-
Manage departments
-
View company reports
-
Allocate licenses
Cannot:
-
Access other companies
-
Change global configuration
Department Manager
Can:
-
Manage users within assigned departments
-
View department reports
-
Assign courses within departments
Cannot manage the entire company.
Learner
Can access assigned courses and view personal progress but cannot manage users or courses.
How Users Are Created and Assigned
Users can be added to IOMAD in several ways depending on the size of the organization.
Manual Creation
Administrators can manually create users by:
-
Creating the account
-
Assigning a company
-
Assigning a department
-
Assigning a role
-
Assigning courses
Manual creation works well for small numbers of users.
Bulk Upload
Most large IOMAD installations rely on CSV uploads.
Typical CSV fields include:
-
Username
-
Email
-
First name
-
Last name
-
Company
-
Department
-
Role
Bulk uploads allow thousands of users to be created quickly and consistently.
Automated User Creation
Many organizations automate user creation using:
-
External database synchronization
-
HR systems
-
SSO integrations
-
APIs
Automation reduces manual errors and simplifies ongoing maintenance.
Common IOMAD User Management Problems
Many IOMAD user management issues are caused by structural configuration rather than software bugs. In multi-tenant environments, companies, departments, roles, and licenses interact in ways that are not always obvious. As the number of tenants grows, small configuration mistakes can create confusing behavior for administrators and learners.
Understanding these common problems makes troubleshooting much faster.
Users Appearing in the Wrong Company
One of the most frequent issues in IOMAD environments is users appearing under the wrong company or unexpectedly gaining access to another tenant.
This usually happens when:
-
CSV uploads contain incorrect company names
-
Synchronization scripts overwrite company assignments
-
Users are manually assigned to multiple companies
-
Company names change but integration scripts are not updated
Company matching often depends on exact naming. Even small differences in spelling or capitalization may create duplicate companies or assign users incorrectly.
In automated environments, external integrations such as HR systems or SSO providers may continuously reassign users if mapping rules are not aligned with IOMAD company definitions.
Administrators should verify both the company assignment and the synchronization source when diagnosing this issue.
Department Structures Becoming Difficult to Manage
Departments are intended to simplify large companies, but poorly designed department hierarchies can make user management more complicated.
Common problems include:
-
Too many department levels
-
Duplicate department names
-
Departments created through CSV uploads unintentionally
-
Departments left unused after organizational changes
Complex hierarchies make it difficult for department managers to locate users and can lead to incorrect reporting.
For example, if departments are nested too deeply, department managers may not realize which users fall under their responsibility.
Departments that are created automatically through uploads may also produce inconsistent naming such as:
-
Sales
-
Sales Team
-
Sales Dept
-
Sales Department
These inconsistencies make reporting and filtering unreliable.
Regular review and cleanup of department structures helps prevent long term confusion.
Courses Not Visible to Users
Another common problem is users not being able to see courses that administrators believe have been assigned.
This often results from multiple layers of assignment.
Course access depends on:
-
Company course assignment
-
Department assignment
-
User enrolment
-
License availability
-
Role permissions
A course may be correctly assigned at one level but blocked at another.
For example:
-
A course assigned to a company may still require enrolment
-
A user enrolled in a course may not have a license
-
A license may exist but not be allocated
-
A department manager may assign a course outside their scope
Because course visibility depends on several conditions, administrators often assume something is broken when the problem is actually structural.
Checking company assignment and license allocation usually identifies the cause.
License Allocation Confusion
License management is a core feature of IOMAD and a frequent source of confusion.
Typical issues include:
-
Licenses available but not allocated
-
Licenses assigned to wrong departments
-
License limits reached unexpectedly
-
Expired licenses preventing enrolment
Administrators may see available licenses at the company level but not realize they have not been allocated to departments or users.
In large environments, license allocation is often automated. If synchronization fails, users may lose access even though licenses still exist.
License reporting should be reviewed regularly to prevent unexpected access problems.
Role and Permission Conflicts
Permission conflicts often occur when users have multiple roles across different contexts.
Examples include:
-
A user acting as both learner and manager
-
Department managers assigned outside their departments
-
Company administrators assigned global roles
-
Custom roles overriding standard permissions
Because Moodle permissions are cumulative, additional roles can grant unexpected capabilities.
For example, a user assigned as a department manager in one area may gain broader visibility than intended.
Permission issues often appear as:
-
Users seeing too many courses
-
Managers seeing incorrect reports
-
Administrators unable to edit users
-
Departments not visible to managers
Careful role assignment and periodic role audits help prevent these problems.
CSV Upload Inconsistencies
CSV uploads are essential for large IOMAD environments, but they introduce risks if not standardized.
Typical issues include:
-
Inconsistent company names
-
Inconsistent department names
-
Incorrect role names
-
Duplicate user accounts
-
Missing required fields
Small formatting differences may cause IOMAD to create new companies or departments instead of using existing ones.
For example:
-
“Company A”
-
“CompanyA”
-
“Company A “
These may be interpreted as different companies.
Standardized CSV templates and validation procedures reduce these problems significantly.
Best Practices for Stable IOMAD User Management
Experienced administrators maintain stable IOMAD environments by following consistent structural rules. Good design reduces support requests, prevents permission conflicts, and makes the system easier to maintain.
The most stable environments are usually the simplest ones.
Keep the Company Structure Simple
Companies should represent true tenant boundaries rather than internal organization.
Most environments work best with:
-
One company per client organization
-
Departments used for internal grouping
Creating too many companies introduces unnecessary complexity in:
-
Reporting
-
Licensing
-
Integrations
-
Administration
Before creating a new company, administrators should confirm that departments cannot solve the requirement.
Simple company structures scale much more reliably.
Design Departments for Administration, Not Just Reporting
Departments should support administrative workflows rather than just organizational charts.
Effective department structures:
-
Match how managers supervise users
-
Allow easy filtering
-
Support reporting
-
Support license allocation
Ineffective department structures often mirror corporate org charts too closely, resulting in unnecessary complexity.
Departments should be practical and easy to understand.
A well designed structure allows administrators to locate users quickly without navigating multiple levels.
Standardize Naming Conventions
Consistent naming is essential for automation and reporting.
Administrators should standardize:
-
Company names
-
Department names
-
Role names
-
CSV templates
For example:
Good:
-
Canada
-
United States
-
Europe
Poor:
-
CA
-
Canada Office
-
Canada Region
Consistent naming prevents synchronization problems and duplicate structures.
Documentation should define the official naming format.
Limit Multi Company Assignments
While IOMAD allows users to belong to multiple companies, this should be used sparingly.
Multi-company users complicate:
-
Reporting
-
Course visibility
-
Dashboards
-
Permissions
They may also create confusion for administrators who expect users to belong to a single tenant.
Most environments function best when users belong to only one company.
Cross-company assignments should be reserved for special cases such as instructors or auditors.
Control Role Assignments Carefully
Role assignments should be predictable and consistent.
Recommended practices include:
-
Limiting global roles
-
Using standard company roles
-
Avoiding unnecessary custom roles
-
Reviewing role assignments periodically
Global roles should be restricted to technical administrators.
Company administrators should operate only within their own tenant.
Predictable role assignments make troubleshooting much easier.
Use Controlled CSV Processes
CSV uploads should follow controlled procedures rather than ad hoc imports.
Recommended practices include:
-
Using standardized templates
-
Validating company names
-
Validating department names
-
Testing uploads on staging environments
-
Keeping versioned CSV templates
Large environments often rely heavily on CSV imports, and small mistakes can affect hundreds or thousands of users.
Controlled processes reduce risk.
Plan for Growth Early
User management structures should be designed with future growth in mind.
Administrators should consider:
-
Expected number of companies
-
Expected number of users
-
Integration requirements
-
Reporting needs
-
Licensing models
Restructuring companies and departments after thousands of users are active can be difficult and disruptive.
Early planning prevents major structural changes later.
From Confusing Permissions to Clear Structure
User management in IOMAD involves multiple layers of configuration including companies, departments, roles, course assignments, and licensing rules. While the system is powerful, small configuration mistakes can lead to users appearing in the wrong company, missing courses, incorrect reports, or permission conflicts that are difficult to trace. Experienced Moodle specialists understand how these components interact and can design user structures that remain stable as organizations grow and integrations are added.
Working with experienced Moodle experts reduces long term administrative effort and prevents structural problems that often require major cleanup later. Instead of reacting to user access issues and inconsistent data, organizations can rely on a well planned user management framework that supports automation, accurate reporting, and reliable multi-tenant operation.
