Moodle roles and permissions can become surprisingly confusing, especially as a school grows. A teacher may suddenly see courses outside their department. A principal may be able to open a course but not access the reports they need. Support staff may have more administrative access than expected, while another user with the same job title appears to have completely different permissions.
These problems are often described as Moodle permission bugs, but the role itself is not always the real issue. In Moodle, access depends on where a role is assigned, which capabilities it contains, what other roles the user already has, and whether another permission or override changes the final result.
For school administrators, the challenge is that Moodle’s technical access structure does not automatically match the school’s organizational structure. A principal, department head, teacher, observer, and support employee may each need access to a different combination of courses, reports, learners, and administrative tools.
Without a clear role strategy, schools often solve one access problem by giving a user broader permissions, only to create a new visibility or security issue elsewhere.
I am Director of Rahab Ministry (a program of Youth Unlimited). We are impressed with Mindfield’s IT specialists in helping us redesign a website (Rahab.yugta.ca) and their ongoing support. They were responsive and helped us think ahead instead of waiting for us to tell them what needed to be done. We will continue to look forward to their support.
Joanna Yee
Owner, Student First Media Inc.
review Source: Google Reviews
Outline
-
Why Moodle Roles and Permissions Can Be Confusing
-
System Roles vs Category Roles vs Course Roles
-
Common Reasons Users Cannot See the Right Courses, Reports, or Activities
-
Custom Roles for Executives, Managers, Instructors, Observers, and Support Staff
-
How to Diagnose Moodle Role and Permission Problems
-
Preventing Permission Problems as Your Organization Grows
-
Designing Access That Matches How Your Organization Actually Works
-
Frequently Asked Questions(FAQs)
Why Moodle Roles and Permissions Can Be Confusing
The first source of confusion is simple: a Moodle role is not the same thing as a job title.
A person may be a teacher in the school, but Moodle does not automatically know which courses they teach. A person may be a principal, but Moodle does not automatically know which school, department, or group of courses that principal should oversee.
The role only defines what actions the user may be allowed to perform. The actual result also depends on where that role is assigned.
This means two users with the same role name can have very different access.
One teacher may have the Teacher role in three individual courses. Another may have a similar role assigned at the category level and therefore receive access across every course in that category. A third user may have several roles at once, with permissions coming from different parts of the site.
Another common source of confusion is that several different Moodle concepts are often treated as if they mean the same thing:
- Course visibility determines whether a course appears to the user.
- Enrolment determines whether the user is enrolled as a participant.
- Role assignment determines what the user may be allowed to do.
- Capabilities control individual actions, such as viewing reports or grading activities.
A user seeing a course does not always mean they are enrolled in it. Being enrolled does not guarantee they can see a hidden course. Being able to open a course does not automatically mean they can access its reports.
This is why permission issues can appear inconsistent from an administrator’s perspective. The administrator may be looking at the role assignment while the real problem is related to enrolment, category access, a hidden course, a missing reporting capability, or a local override.
The safest approach is to stop asking only:
“What role does this user have?”
A better set of questions is:
- What does this person actually need to do?
- Where do they need to do it?
- Which courses or departments should they access?
- What should they definitely not be able to see or change?
These questions lead directly to the most important part of Moodle permission planning: context.
System Roles vs Category Roles vs Course Roles
Many Moodle access problems begin when the correct role is assigned at the wrong level.
Moodle uses a hierarchy of contexts. A role assigned at a higher level can affect lower levels underneath it. For schools, the three contexts that matter most are system, course category, and individual course.
| Role Scope | Where It Applies | Common Use | Common Mistake |
|---|---|---|---|
| System | Entire Moodle site | LMS administrators or carefully limited support roles | Giving site-wide access for a limited responsibility |
| Category | A category and its courses | Executives, program managers, department heads | Assigning the role too high in the category hierarchy |
| Course | One individual course | Instructors, teaching assistants, course observers | Repeating manual assignments when broader access is required |
System Roles
A system role applies across the Moodle site.
This can be appropriate for someone who genuinely needs sitewide responsibilities, such as a central LMS administrator responsible for users, configuration, troubleshooting, reporting, and course support across the entire platform.
The problem begins when a system role is used simply because it is the fastest way to solve an access request.
For example, giving a principal the Manager role at the system level may allow them to open the reports they requested. However, it may also give them access to courses, users, and administrative functions across every school or department.
The same issue can happen with support staff. Giving a support employee full administrative access may solve almost every ticket, but it may also provide access to sensitive settings and learner information they do not need.
A system role should therefore be used only when the person genuinely needs the relevant permissions across the entire site.
Category Roles
Category roles are often a better match for school leadership structures.
A school may organize its Moodle courses by faculty, campus, academic year, program, department, or grade level. A user assigned a role within one of these categories can receive that role across the courses below it.
For example, a principal responsible for one school may need access to all courses in that school’s category. A department head may need access to the Mathematics category without seeing courses in Science or English.
This is usually much safer than giving the same user a sitewide role.
However, category structure matters. If a role is assigned too high in the hierarchy, the user may inherit access to more courses than expected. Subcategories may also extend the access further than the administrator intended.
Category roles can create another confusing situation. A user may be able to enter a course through a category level role even though they are not enrolled as a normal course participant. This can explain why someone can access the course but does not appear where expected in the Participants list.
Course Roles
Course roles are the most familiar type of Moodle assignment.
They are commonly used for teachers, students, teaching assistants, guest instructors, and course specific observers. Their permissions remain connected to the individual course.
For a teacher responsible for three specific courses, course level assignment usually makes sense. For a department head responsible for fifty courses, repeating the same assignment manually may be inefficient and difficult to maintain.
A useful rule is:
Assign a role at the highest context the user genuinely needs, but no higher.
A teacher who needs three courses should not receive a sitewide role. A department head responsible for one department should not automatically become a system Manager. A principal responsible for one school should not gain access to every school just because broader permissions were easier to configure.
Common Reasons Users Cannot See the Right Courses, Reports, or Activities
When Moodle access looks wrong, avoid changing permissions immediately. First identify where the problem appears and what the user is supposed to access.
The most common causes are:
1. The Role Is Assigned at the Wrong Level
A role can be correct but assigned too broadly or too narrowly.
For example, a manager who needs access to one department should not receive a system-wide Manager role.
Check: System, category, and course-level assignments.
2. The User Has Multiple Roles
One user can receive permissions from several places at once.
Check for:
- System roles
- Category roles
- Course roles
- Older assignments
- Local overrides
Removing one role does not necessarily remove the user’s other sources of access.
3. Visibility and Enrolment Are Being Confused
Seeing a course, being enrolled in it, and having permission to manage it are different things.
Always identify where the issue occurs:
- Dashboard
- Category
- Catalogue
- Course page
- Activity
4. The User Is Missing a Specific Capability
Being able to enter a course does not automatically provide access to reports, grades, logs, or administrative functions.
Define the exact action the user needs before adding permissions.
5. A Local Override or Activity Restriction Is Changing Access
If the issue occurs in only one course or activity, check local permissions and restrictions before changing the user’s main role.
Restrictions can also depend on:
- Groups
- Grades
- Completion
- Dates
- Profile fields
6. An Automated Process Keeps Restoring Access
Access can come from:
- Cohorts
- CSV imports
- LDAP
- Student or HR systems
- External databases
- Automated enrolment
- Custom integrations
If access returns after being removed manually, identify which process owns the assignment instead of repeatedly removing it.
How These Roles Translate Outside Schools
Moodle role design is based on responsibilities, not job titles. The same access model can apply to schools, businesses, nonprofits, associations, and training providers even when each organization uses different titles.
| Access Function | School | Business | Nonprofit | Typical Moodle Scope |
|---|---|---|---|---|
| Executive Oversight | Principal / Director | CEO / VP / Director | Executive Director | Category or reporting role |
| Department Oversight | Department Head | Department Manager | Program Manager | Category |
| Learning Delivery | Teacher / Instructor | Trainer / Facilitator | Program Facilitator | Course |
| Read-Only Oversight | Observer / Mentor | Supervisor / Auditor | Board Member / Program Reviewer | User, course, or category |
| Platform Support | LMS / IT Support | IT / LMS Support | Systems / Program Support | Limited system or category role |
The job title matters less than three questions:
- What does this person need to do?
- Where do they need to do it?
- What should they not be able to access?
Those questions determine the Moodle role and context more reliably than organizational titles.
Custom Roles for Executives, Managers, Instructors, Observers, and Support Staff
Standard Moodle roles are a useful starting point, but many organizations eventually need access models that better reflect real responsibilities.
The goal is not to create a separate role for every job title. Instead, create roles around recurring access needs.
For example:
- Executives or senior leaders usually need visibility into progress, completion, grades, and reports without course editing access.
- Department or program managers may need oversight of courses and learners within one category or business area.
- Instructors or trainers usually need course-level access to manage content, activities, grading, and reports.
- Observers, mentors, or auditors typically need carefully limited read-only access.
- Support staff should receive only the troubleshooting permissions required for their responsibilities.
Avoid assigning the full Moodle Manager role simply because it solves an access request quickly. Start with the required tasks, choose the appropriate Moodle context, and provide only the capabilities needed at that level.
The goal is to match access to responsibility—not to job title.
How to Diagnose Moodle Role and Permission Problems
The fastest way to troubleshoot Moodle permissions is to begin with the user’s exact experience rather than immediately editing the role.
A good investigation starts with four questions:
- Which user is affected?
- Which exact course, report, page, or activity is involved?
- What should the user be able to do?
- What can the user actually do now?
Once the symptom is clear, administrators can review the most likely causes.
| Symptom | Areas to Check First |
|---|---|
| User sees too many courses | System roles, category roles, old enrolments, cohorts |
| User cannot find a course | Enrolment, course visibility, category access |
| User can open a course but not a report | Reporting capabilities and role context |
| User can access a course but is missing from Participants | Higher-context role assignment |
| User can see an activity but cannot use it | Activity permissions, groups, and restrictions |
| Problem affects only one course | Course or activity-level overrides |
| Access returns after being removed | Automated enrolment or synchronization |
The administrator should then review the user’s assignments across the full Moodle context hierarchy. Looking only at the Participants page is not enough because relevant access may come from a category or system role.
The next step is to check the user’s effective permissions rather than assuming the role name tells the full story. Several role assignments and overrides can combine to create a result that is not obvious from one role definition.
Testing is also important.
A dedicated test account is often more reliable than simply switching roles, especially when testing permissions that come from system or category assignments.
For a new principal, observer, or support role, schools should test both what the user can do and what the user cannot do.
For example:
- Can the principal edit course content?
- Can the department head access another department?
- Can the observer see private learner information?
- Can the support employee change site configuration?
A role is not fully tested until both the intended permissions and the intended restrictions have been confirmed.
Preventing Permission Problems as Your Organization Grows
Moodle permissions become difficult to manage when access decisions are made one request at a time. Temporary roles, local overrides, automated enrolments, and old assignments can gradually create an access structure that nobody fully understands.
A simpler long-term approach is to:
- Document recurring roles: Define what each role is designed to do and where it should be assigned.
- Use clear role names: Choose names such as Department Manager, Reporting Access, or Limited Support instead of Manager Copy or New Role 3.
- Review system-level roles regularly: Remove outdated, temporary, or unnecessarily broad assignments.
- Minimize local overrides: Too many course- or activity-level exceptions become difficult to trace.
- Audit roles after Moodle upgrades: New capabilities, plugins, and reports can change what custom roles are able to access.
- Fix scope before adding permissions: If a user has the wrong access, first check whether the role is assigned at the wrong system, category, or course level.
The most important rule is simple:
Give users the right access at the right scope—not simply more access.
Designing Access That Matches How Your Organization Actually Works
Moodle role problems often become difficult because they involve several systems at the same time. A course visibility issue may involve permissions, enrolment methods, cohorts, category structure, dashboard behavior, custom reports, or third party plugins. Changing one capability can appear to solve the problem while creating unexpected access somewhere else.
An experienced Moodle expert can review the school’s organizational structure, identify inherited or conflicting role assignments, design custom roles for leadership and support teams, and test the final access model through real user accounts. This is especially valuable for schools with multiple campuses, departments, custom reporting needs, large numbers of users, or complex integrations.
The goal is not to create more roles. It is to create a simpler and more predictable system where principals see the information they need, teachers manage the correct courses, observers remain appropriately limited, and support employees can solve problems without receiving unnecessary administrator access.
Frequently Asked Questions (FAQs)
