Administrators managing a multi tenant Moodle environment using IOMAD often expect each organization or tenant to see only their own courses. However, it is not uncommon to encounter situations where the course catalog displays incorrect, unrelated, or even restricted courses across tenants.
This article specifically focuses on Moodle IOMAD’s multi tenancy model, which differs from Moodle Workplace in how tenants (companies), catalogs, and course visibility are structured and controlled. While both platforms support multi tenancy, the root causes and solutions discussed here are tailored to IOMAD environments.
This issue can create confusion for users, compromise tenant separation, and reduce trust in the learning platform. Understanding the root causes and applying the correct fixes is essential for maintaining a clean and secure multi tenant setup.
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
What Is Actually Happening Behind the Catalog
When the Moodle catalog shows incorrect courses, the platform is not randomly displaying content. Instead, it is following visibility rules that are broader or misaligned with your intended tenant structure.
In a multi tenant setup, course visibility is controlled by several overlapping systems. These include company or tenant assignment, course category structure, enrollment methods, cohort relationships, and user permissions. The catalog simply reflects the result of how these systems combine.
For example, a course may be correctly assigned to a tenant but placed inside a globally visible category. In that case, the catalog may still display it to users from other tenants. Similarly, a user might not see a course even though it belongs to their tenant if cohort sync or enrollment linkage is missing.
What appears as a catalog problem is often a symptom of inconsistencies between visibility, access, and enrollment logic. This is why quick fixes at the catalog level alone rarely solve the issue completely.
Why Course Visibility Breaks in Multi Tenant Moodle
There are several common patterns that lead to incorrect catalog behavior, and they often occur together rather than in isolation.
One of the most frequent causes is improper tenant or company assignment. If a course is not explicitly tied to the correct tenant, it may default to a broader visibility scope. This becomes especially problematic in environments where courses are duplicated or imported without reassigning ownership.
Another major factor is category structure. When multiple tenants share the same course categories, visibility rules can overlap. Even if courses are logically separated, the category itself may expose them to unintended users.
Enrollment methods also play a significant role. Features such as self enrollment or guest access can bypass tenant restrictions entirely if not carefully controlled. A course that is technically assigned to one tenant can still appear visible to others simply because enrollment is open.
Permissions add another layer of complexity. Roles assigned at the system or category level may override tenant restrictions. For instance, a user with broader browsing capabilities may see courses across tenants even if they cannot enroll in them.
Finally, cohort sync issues often create confusion between visibility and access. A course might appear in the catalog but remain inaccessible because the user is not properly linked through cohorts. This mismatch leads to a poor user experience and makes troubleshooting more difficult.
How to Fix Incorrect Course Visibility Step by Step
Fixing catalog issues requires a structured approach that addresses all layers of the system, not just the surface level symptoms.
Start by verifying tenant or company assignment for every affected course. Each course should be explicitly linked to the correct tenant, with no ambiguity or fallback to global visibility. This is the foundation of proper separation.
Next, review your course category structure. Ideally, each tenant should have its own dedicated category hierarchy. Shared categories should only be used when intentional and carefully controlled. This prevents visibility leakage across tenants.
Then, examine enrollment methods across your courses. Disable or restrict self enrollment and guest access unless they are absolutely necessary. If they are required, ensure they are configured in a way that respects tenant boundaries.
Cohort sync should also be carefully audited. Confirm that users are placed in the correct cohorts and that those cohorts are properly linked to courses. This ensures that visibility aligns with actual access and enrollment.
Permissions must be reviewed at multiple levels. Check system roles, category roles, and course roles to ensure that no capability unintentionally allows cross tenant browsing. Even a single overly permissive role can affect the entire catalog.
Finally, always test changes using a standard user account within a tenant. Administrator accounts often bypass restrictions, so testing with real user roles is essential to confirm that the catalog behaves correctly.
Long Term Strategy for Stable Multi Tenant Catalogs
Preventing catalog issues in the long run requires consistency, structure, and clear governance over how courses are created and managed.
A strong category architecture is one of the most important foundations. Each tenant should have clearly defined and isolated categories, with minimal overlap. This makes visibility rules more predictable and easier to maintain.
Standardizing course creation workflows is equally important. Every new course should follow the same process for tenant assignment, category placement, and enrollment configuration. This reduces the risk of human error.
Regular audits of roles and permissions help catch issues early. As platforms grow, permissions tend to become more complex, and periodic reviews ensure that access remains aligned with tenant boundaries.
It is also important to limit the use of global features such as open enrollment or shared categories unless they are intentionally designed into the system. These features can be useful, but they must be used with clear rules and documentation.
Documenting your multi tenant setup, including how courses should be assigned and how visibility is controlled, creates consistency across administrators and reduces reliance on trial and error troubleshooting.
Keeping Tenant Boundaries Intact with Expert Moodle Support
Multi tenant Moodle environments built on IOMAD rely on a delicate balance between company assignment, category structure, enrollment methods, and permissions. When something goes wrong, such as courses appearing in the wrong catalog, the issue is rarely isolated. It often involves multiple layers of configuration interacting in unexpected ways, making it difficult to diagnose and fix without deep platform knowledge.
Unlike Moodle Workplace, where tenant isolation is more tightly managed through built in structures, IOMAD requires careful configuration and ongoing governance to ensure proper separation between companies. This makes it especially important to approach catalog issues with a full understanding of how IOMAD handles visibility and access.
Working with experienced Moodle experts ensures that these issues are resolved at the root level rather than just on the surface. Moodle experts can audit your IOMAD tenant architecture, align course visibility with enrollment logic, and implement best practices that prevent cross tenant leakage. More importantly, they help establish a scalable and standardized structure so that as your platform grows, your catalog remains accurate, secure, and easy to manage.
