Why Moodle™ Course Completion Breaks for 90% of Courses?

Course completion is one of the most useful features in Moodle™, particularly for corporate training, compliance programmes, certification courses and structured learning pathways. It gives learning teams a simple answer to an important question: has this learner completed the course or not?

Yet course completion is also one of those areas where problems often appear months after a course has been launched. A course that worked perfectly when it was created suddenly starts showing learners as incomplete. Administrators discover an old activity buried inside a section that is still required for completion. An updated assessment creates unexpected behaviour. A resource that nobody considers important is preventing certificates from being issued.

In many cases, Moodle™ LMS itself is not the problem. The problem is the way the completion architecture was originally designed for the course.

A common approach is to make almost every activity in the course part of the course completion criteria. If a course contains 25 activities, all 25 are selected under Course completion > Activity completion, with the assumption that this provides the strongest possible evidence that the learner completed everything. It sounds logical. Operationally, however, it creates a fragile course.

A much more maintainable approach is to separate activity completion, learning progression and course completion. Moodle™ can track many activities, but only a small number of stable, meaningful activities should normally determine whether the entire course is complete.

Activity completion and course completion are not the same thing

This distinction is fundamental. Activity completion tells Moodle™ whether a particular activity has satisfied its configured requirements. Depending on the activity, this could mean that the learner viewed a Page, submitted an Assignment, received a grade, passed a Quiz, posted in a Forum or manually marked something as done.

Course completion operates at a higher level. Moodle allows selected activities to become criteria for completing the entire course, and those criteria can be aggregated using rules such as ALL or ANY.

The fact that an activity has completion tracking enabled, however, does not mean that it needs to be included directly in the course completion criteria. That is where many course designs become unnecessarily complicated.

Imagine a course containing:

• 4 Pages
• 6 Assignments
• 3 H5P activities
• 2 downloadable file resources
• 3 knowledge check quiz
• 1 final assessment quiz
• 1 feedback activity
• 1 certificate

If every one of these activities becomes a course completion requirement, Moodle™ now has more than twenty different dependencies that must continue working correctly for every learner.

Some of those dependencies may represent real learning requirements. Others may simply be resources that happened to have activity completion enabled when the course was originally built. The larger that dependency chain becomes, the more difficult the course becomes to maintain.

The hidden problem appears when the course changes

Corporate learning courses rarely remain unchanged.

Policies change. Procedures are updated. A PDF is replaced. A video becomes outdated. A SCORM package is replaced with a newer version. A knowledge check is rewritten. An administrator adds a new Page explaining a process that did not exist when the course was originally launched. Course completion needs to survive these routine changes.

This is particularly important because Moodle™ completion represents a recorded state rather than a permanent verification that the learner has seen the latest version of every piece of content.

Once someone has completed an activity, Moodle™ protects its completion settings. The official documentation explains that completion options become locked after a person completes the activity because changing those rules can produce unexpected results. If an administrator unlocks and changes the completion conditions, the existing completion information is deleted and recalculated where possible; manual completion cannot simply be reconstructed automatically.

This distinction has an important operational consequence. Editing the content inside an activity is not the same as changing its completion rules.

If somebody viewed a Page last month and Moodle™ marked that Page complete because the requirement was simply “View the activity”, changing some text on that Page today does not automatically mean Moodle can determine that the learner has not seen the new version.

From a maintenance perspective, this is often useful. You do not want thousands of employees suddenly becoming incomplete every time somebody corrects a spelling mistake or updates a paragraph.

But it also means we should not design course completion as though every individual resource provides permanent evidence of learning.

Why selecting every activity creates fragile course completion

The more activities directly connected to course completion, the more tightly coupled the course structure becomes to its historical design.

Suppose a learning designer initially builds a course with twelve resources and a final quiz. All thirteen activities are selected as course completion criteria. Six months later, the organisation decides that three of those resources should be replaced. Another document becomes optional reference material. A new video is introduced. The final assessment remains essentially the same.

What should happen to learners who completed the course six months ago? Should they lose their course completion because an administrator replaced a document? Should they be required to open a new introductory Page simply because the learning team restructured the course? Should completion records for historical learners change because today’s course structure is different?

Usually the answer is no.

Completion records are often being used for reporting, certification, HR records, compliance evidence or programme enrolment. They should not casually change because somebody reorganised the course page.

Moodle™ itself describes course completion principally as a reporting mechanism rather than as an access-control system. That is why completion architecture should be deliberately conservative.

Think in terms of milestones instead of activities

A better question is not: “Which activities does the learner need to open?”

The better question is: “What reliable evidence tells us that the learner has reached the required learning milestone?”

For many courses, the answer might be a final assessment. For another course it might be three end-of-module quizzes plus a declaration. For a practical training programme it could be an assignment submission followed by trainer approval.

These are much stronger course completion criteria than twenty individual Pages and Files. The objective should be to identify a small number of durable milestone activities that represent successful progression through the course.

That might mean only one to five activities determine course completion even though twenty or thirty activities have activity completion enabled.

The other activities can still be tracked. They simply do not all need a direct connection to the final course-completion record.

Use gated activities to enforce the learning pathway

This is where Moodle’s Restrict access feature becomes extremely useful. Instead of making every activity a course completion criterion, use activity completion to control whether the learner can reach the next important milestone.

Moodle™ can restrict access to an activity based on conditions such as completion of another activity, a grade, date, group, grouping or user profile information. It can also restrict an activity based on completion of the previous activity.

This allows us to create what we might call gatekeeper activities. Consider a course structured like this:

Module 1

The learner must view the policy introduction, watch a video and complete a short knowledge check. The knowledge check is restricted until the required learning materials have been completed.

Module 2

The learner completes another set of learning activities and reaches a second checkpoint.

Module 3

The same process continues for all subsequent modules.

Final assessment

The final assessment remains unavailable until the learner has completed the required module checkpoints. The learner therefore cannot reach the final assessment without satisfying the earlier requirements.

Now comes the important part: Course completion does not necessarily need to check every earlier activity again.

The final assessment can become one of the main course completion criteria because access to that assessment already proves that the learner satisfied the prerequisite pathway.

Instead of having: Course Completion = Activity 1 + Activity 2 + Activity 3 + Activity 4 + Activity 5 + Activity 6 + Activity 7 + Activity 8 + Quiz

we can design: Activities 1–8 → unlock Final Assessment → passing Final Assessment = Course Completion

The required learning pathway is still enforced, but the course completion configuration becomes dramatically simpler.

Not every Page needs activity completion either

There is another temptation worth avoiding: enabling completion tracking simply because an activity exists. A Page containing supplementary information does not necessarily need completion tracking. Neither does every File, URL or optional video.

Completion should have a purpose. Ask why the activity is being tracked. If the answer is: “We need learners to see their progress.” Activity completion may make sense.

But if the answer is: “Learners must complete this before accessing the next activity.” Activity completion definitely has a functional purpose because it is being used with Restrict access.

If the answer is: “This provides evidence that the learning outcome has been achieved.” It may also deserve inclusion in the course completion criteria.

But if the only explanation is: “We normally enable completion on everything,” the course probably needs to be reconsidered.

Be especially careful with “view activity” completion

Requiring a learner to view a resource is useful for navigation and progression, but organisations should be careful about interpreting it as meaningful learning evidence.

A completed Page generally proves that Moodle recorded the required interaction. It does not prove that the learner understood the Page, carefully read every paragraph or remembers the material.

The difference matters particularly in compliance and regulatory training.

Instead of making ten Pages direct course completion criteria, it can be more meaningful to let those Pages unlock a knowledge check. Passing the knowledge check then becomes a stronger milestone.

The learner still has to progress through the material, while the completion record is linked to something that more closely represents the intended learning outcome.

Fewer criteria also make troubleshooting much easier

There is an operational advantage that becomes obvious when managing hundreds of learners. Imagine an employee contacts the learning team: “I finished the course, but Moodle still says I haven’t completed it.”

If the course contains thirty completion criteria, the administrator must work through a substantial list looking for the missing condition. Perhaps an activity is hidden. Perhaps an old manual completion condition remains. Perhaps a Quiz expects a passing grade that has not been configured correctly. Perhaps a learner skipped one Page. Or perhaps the activity’s completion settings were changed after learners had already started using the course.

The Moodle™ documentation specifically warns that changing locked activity-completion settings can delete existing completion information and trigger recalculation.

When only two or three milestone activities control course completion, troubleshooting becomes considerably faster. Administrators can immediately ask:

• Did the learner complete Checkpoint 1?
• Did they complete Checkpoint 2?
• Did they pass the final assessment?

The completion logic is easy to explain, document and support.

Course completion should be stable even when content evolves

This is perhaps the most important design principle. Course content should be allowed to evolve without unnecessarily destabilising historical completion records.

Learning teams should expect Pages, Files, videos and examples to change. Routine content maintenance should not require rebuilding completion logic every time. The activities directly tied to course completion should therefore be relatively stable.

Assessments, formal acknowledgements, graded assignments, competency checks and carefully designed milestone activities are often better candidates than ordinary learning resources. Meanwhile, activity completion and Restrict access can handle the detailed learner journey inside the course.

This creates two layers:

Progression layer: Activity completion + Restrict access determine how learners move through the course.

Certification/reporting layer: A few carefully chosen milestone activities determine whether the overall course is complete.

That separation is much easier to manage over the lifetime of a course.

What about major course updates?

There is an important exception.

If the learning itself changes substantially – for example, a regulation changes, a new safety procedure is introduced or employees are legally required to undertake updated training — simply modifying an existing Page should not be expected to make previous learners “uncomplete”.

That is a training governance problem rather than merely a completion-setting problem.

In those situations, organisations should consider approaches such as creating a new version of the course, defining retraining requirements, resetting completion in a controlled manner where appropriate, creating a refresher course or enrolling affected users into a new learning requirement.

Trying to make ordinary activity completion automatically represent course versioning can quickly create unreliable reporting. Course completion answers: “Did this learner complete the defined requirements?”

It does not automatically answer: “Has this learner reviewed every revision ever made to this course?”

Those are different requirements and should be designed differently.

A practical completion architecture for corporate courses

For many corporate courses, a maintainable model might look something like this:

• Learning resources: Enable completion only where it genuinely helps progression or reporting.
• Required activities: Use activity completion where learners genuinely need to perform something.
• Progression: Use Restrict access so that important checkpoints cannot be reached until prerequisite activities have been completed.
• Module checkpoints: Use a small number of quizzes, assignments or other measurable activities to verify progression.
• Final assessment: Gate access until the necessary earlier requirements have been satisfied.
• Course completion: Base it primarily on the final assessment and, where necessary, a few additional formal milestones.
• Certificate: Make the certificate available only after the required completion condition or final assessment has been satisfied.

The exact configuration will differ between courses, but the design principle remains the same:

Track what is useful, restrict what is required, and use only meaningful milestones for course completion.

Before changing an existing course, audit the completion architecture

If you already have live courses where almost every activity forms part of course completion, do not start changing the settings blindly. Completion data may already exist.

Because Moodle™ locks activity-completion settings once users have completed an activity, unlocking those settings can cause completion information to be deleted and recalculated. Moodle™ explicitly advises caution when doing this on courses that are already in use.

Start by reviewing:

1. Which activities currently have activity completion enabled.
2. Which activities are directly included in course completion.
3. Which activities are being used in Restrict access conditions.
4. Which completion rules provide actual evidence of learning.
5. Which rules exist only because they were configured when the course was originally built.
6. Whether learners have already completed the course and whether historical records need to be preserved.

Only after understanding those dependencies should the completion architecture be simplified.

The goal is not fewer requirements – it is fewer fragile dependencies

Reducing the number of course completion criteria does not mean making the course easier. Learners can still be required to complete ten, twenty or thirty activities. The difference is architectural.

Instead of asking course completion to monitor every individual requirement independently, Moodle’s activity completion and Restrict access features can enforce the learning journey. Carefully chosen checkpoint activities then provide evidence that the learner successfully moved through that journey.

The result is a course that is easier to update, easier to explain, easier to troubleshoot and far less likely to develop mysterious completion problems months after launch.

For organisations running large Moodle™ environments, that matters. A completion configuration that appears harmless in a course with twenty learners can become a significant support problem when the same architecture is duplicated across hundreds of courses and thousands of employees.

Course completion should therefore be treated as part of the course’s long-term technical design, not simply as a checklist to configure before launch.

The safest principle is simple: don’t make every activity responsible for completing the course. Use activity completion to track the journey, Restrict access to create gates, and reserve course completion for the few milestones that genuinely prove the learner has reached the end.

Make Course Maintenance Part of Your Managed LMS Support

Course completion settings are only one of the many areas that need regular attention as an LMS grows. Over time, changes to activities, assessments, access restrictions and learning pathways can create hidden dependencies that are difficult for internal learning teams to identify until learners start reporting problems.

With LMSDaily Managed Support Services, our specialist team takes care of this ongoing LMS maintenance for you. We review and maintain course completion rules, activity completion settings, gated learning pathways, access restrictions and other configuration details that can affect the learner experience and reporting.

Rather than waiting for completion problems to appear, we help keep your courses structured, maintainable and aligned with your learning requirements as they evolve.

If your learning team is spending too much time troubleshooting LMS configuration, updating courses and resolving issues that require specialist knowledge, LMSDaily can provide the ongoing technical support needed to keep your LMS running smoothly while your team focuses on learning and training.