Use Moodle Core Completion Instead of Custom Progress Tracking

Product teams often ask for a gated learning path: view this page, pass that quiz, submit an assignment, then unlock a certificate. The engineering temptation is to build custom tracking code. Moodle already ships a declarative completion system for activities and courses that can express those gates without plugins.

The problem with rolling your own tracking

Custom completion means new tables, cron jobs, and UI to keep in sync with gradebook changes. It also duplicates logic that Moodle already maintains per activity module. Core completion provides per-activity rules and course-level criteria with AND/OR logic, plus events that feed reports, badges, and learning analytics.

Activity completion is per module instance. Course completion is separate and evaluates the set of completed activities against criteria you define.

How the two layers work

Enable tracking first. In Course administration > Edit settings, set Completion tracking to Yes. This is a course-level toggle and requires a manager role in that course.

Activity completion rules are set on each resource. Edit the activity, open Completion tracking, and choose a condition. Common options are:

• Manual: teacher marks complete
• Automatic: complete on view, on attempt, on submission, or on passing grade
• Show activity as complete when conditions are met, with an optional completion checkbox for students

Rules differ by activity type and Moodle major release. For example, quiz completion can be tied to attempt and grade threshold, while a forum can be tied to posting. Check the activity's completion settings in a test course before relying on a specific trigger.

Course completion criteria live in Course administration > Course completion. You can require:

• A specific set of activities to be completed
• A minimum number of completed activities
• A final grade threshold

Criteria combine with AND/OR logic. Course completion fires events like course_completed when the criteria are satisfied, which integrates with badges and reports.

A declarative learning path example

A typical pattern for a compliance module is:

1. Page resource "Overview": completion = complete on view
2. Quiz "Knowledge check": completion = complete on attempt with passing grade 80%
3. Assignment "Reflection": completion = complete on submission
4. Course completion: require all three activities with AND logic
5. Certificate module: make it available conditionally on course completion

This defines the path entirely in settings. No custom code is needed to enforce the order. Conditional activity availability reads the completion state on page load and shows or hides the certificate.

Trade-offs and limits

Completion tracking adds database writes per user interaction. Enabling it for every activity in a large course can increase load and reporting time. Review which activities truly need tracking.

Completion checks run on page load and can be affected by caching. Students may expect immediate unlocks after submitting. Communicate that visibility updates on the next page view.

Behavior varies by activity module version. Manual vs automatic rules for quizzes, assignments, and forums can change across Moodle major releases. Verify the exact options in your version.

Access control via completion can confuse users if they expect instant feedback. Use it for progress and unlocks, not for security-sensitive gating.

Check it works

Verify configuration in a test course:

• Enable completion tracking and set activity rules for a resource and a quiz
• As a student user, perform the required actions and open the Completion overview report
• Review Course completion criteria to confirm AND/OR logic is saved
• Check site events for course_completed and mod_*_activity_completed to confirm triggers fire after criteria are met

If the criteria are met but completion does not appear, re-save course settings and clear caches, then re-check the user completion status.

For teams deciding between custom tracking and core features, start with core completion for declarative paths. Reserve custom code for requirements that completion cannot express, such as cross-course progress or complex time-based windows.