Every term starts with two or three weeks of add/drop. A student registers on Tuesday and still can't see the course on Thursday, so they miss the first quiz. Another drops the course but keeps receiving forum notifications. A third switches sections and finds an empty gradebook where last week's work used to be.
Each case becomes a ticket, first to the helpdesk, then to the Moodle team, sometimes to the registrar. Under pressure, teachers start enrolling students by hand, which fixes today's problem and creates a new one later in the term.
Why do students lose access during add/drop?
Moodle does exactly what the enrollment data tells it to do. The trouble lies in when that data arrives, in what order, and how removals are applied.
| Symptom | Likely cause |
|---|---|
| Registered in the SIS, missing in Moodle | Sync runs overnight or weekly; account not created yet; identifier mismatch |
| Dropped, still has access | Sync only adds; unenrol action set to keep users; manual enrollment left behind |
| Switched sections, work is gone | Swap processed as unenroll then enroll; grades removed with the enrollment |
| Lost access without dropping | An SIS status such as waitlisted or provisional mapped to "dropped" |
| Listed twice or in the wrong section | Manual enrollment on top of the synced one; stale section course |
Three root causes explain most of these:
- Batch timing. A nightly or weekly job made sense when enrollments rarely changed. In add/drop week they change by the hour.
- Order of operations. Accounts must exist before enrollments, and a student should be added to the new section before being removed from the old one. Scripts often process records in whatever order the export lists them.
- Destructive removals. Moodle's external database enrolment plugin, for example, lets you choose what happens when a student disappears from the source. If the choice is to unenroll, a temporary gap in the data deletes grades and group memberships.
What does it cost when enrollment lags?
- Students miss the first assessments and readings. New students, the ones least likely to complain, fall behind quietly.
- Faculty spend the first classes checking lists instead of teaching, and lose confidence in Moodle as the source of truth.
- Helpdesk and IT absorb a spike of tickets in the busiest weeks, each requiring a look at both the SIS and Moodle.
- Privacy. A student who dropped but kept access can still read classmates' forum posts and see the participants list. Limiting access to the people who need it is part of what Quebec's Law 25 and the GDPR expect.
Which quick fixes make it worse?
- Running the same batch more often. It shortens the delay but keeps the ordering problems and the destructive removals.
- Letting teachers enroll students manually, or sharing a self-enrolment key. Those enrollments live outside the SIS, so the sync never removes them when a student drops.
- Unenrolling immediately on drop. Moodle can restore grades on re-enrollment when Recover grades default is turned on, but group memberships and role assignments don't come back on their own.
- Deleting and recreating every enrollment in a full resync. Each run becomes a chance to lose data, and the logs fill with noise that hides real changes.
How to fix enrollment sync for add/drop
1. Shorten the delay where it matters
During add/drop, changes should reach Moodle within minutes. After the deadline, a slower schedule is fine. Let the schedule follow the academic calendar rather than a single cron setting for the whole year.
2. Create accounts before enrollments
Provision Moodle accounts from the SIS or the identity provider as soon as a student is admitted, not at their first login. A late admit with no account is the most common reason a valid enrollment never appears.
3. Match on stable identifiers
Match users on their SIS ID number and courses on their course ID number. Names and email addresses change, and a student who updates their preferred name shouldn't lose their courses.
4. Suspend, don't delete
Configure your enrolment plugin so that a student removed from the source is suspended rather than unenrolled. The external unenrol action setting decides this:
| Option | Access | Grades and work | When to use |
|---|---|---|---|
| Unenrol user from course | Removed | Removed from the gradebook | Final cleanup only, after the drop deadline |
| Keep user enrolled | Kept | Kept | When the source lists only the current term and past courses must keep their students |
| Disable course enrolment | Blocked | Kept, roles kept | The safe default during the term |
| Disable course enrolment and remove roles | Blocked | Kept, roles removed | When dropped students should leave grading reports |
Run any final cleanup after the drop deadline, once the registrar has confirmed the lists.
5. Process section swaps as a move
Add the student to the new section first, then remove them from the old one. In a meta-course, both sections feed the same parent, so the student only changes group; see how meta-courses handle section swaps.
6. Keep one source of truth
In SIS-managed courses, reserve manual enrollment for documented exceptions, such as auditors or guests, and record who added them and why. Remove self-enrolment from those courses.
7. Reconcile every day during add/drop
Compare Moodle with the SIS once a day: students in the SIS without a Moodle enrollment, Moodle enrollments without an SIS record, and courses whose counts differ. Fix the cause, not only the individual case.
How to investigate a "student lost access" ticket
When a ticket arrives anyway, check in this order. Most cases are solved by step 3.
- Check the SIS. Confirm the student's current registration status, section and the time of the last change.
- Check the account. In Site administration > Users, find the student by ID number. Make sure the account exists, isn't suspended at user level and uses the expected authentication method.
- Check the enrollment. On the course's participants page, look at the enrolment method and the status: Active, Suspended or Not current. Not current usually means an enrollment start or end date is set.
- Read the logs. Filter the course logs by the student and look for user enrolled, user unenrolled and user enrolment updated events. The origin column shows whether the change came from the web interface, web services or a command-line task.
- Check visibility and restrictions. A hidden course, a future course start date or an activity restricted to one group can look like missing access.
- Fix it at the source. Correct the SIS record or the sync rule, then let the sync apply the change, instead of adding a manual enrollment.
How Classeo handles it
Classeo syncs enrollments from the SIS in real time or on a schedule, so a student who registers late, drops or switches sections sees the change in Moodle within minutes, not the next morning. The edge cases that break homegrown scripts, such as late adds, audit students and section swaps inside meta-courses, follow the SIS rather than manual edits.
Every enrollment change is timestamped and tagged with its actor. When a student says they lost access, the helpdesk can see which change caused it and when, without digging through server logs. The same trail answers privacy officers' questions under Law 25 and the GDPR, as our article on Moodle audit trails and end-of-term archiving explains.
For the IT team, what remains is monitoring and exception handling, usually under four hours a term. The Moodle SIS integration page lists the supported systems, Moodle administration shows what super-users still control, and the FAQ covers sync timing and data handling.
Key takeaways
- Most add/drop problems come from timing and order, not from Moodle itself: nightly batches, missing accounts and drop-then-add section swaps.
- Suspending an enrollment blocks access but keeps grades and work, while unenrolling removes grades, roles and group memberships.
- Manual enrollments by teachers fix today's ticket and create tomorrow's stale access, because the sync never removes them.
- During add/drop, sync within minutes and reconcile Moodle against the SIS every day.
- A log showing which SIS change caused each Moodle change turns a long investigation into a quick lookup.
See an add/drop week without the tickets
A 30-minute demo of Classeo propagating late registrations, drops and section swaps from the SIS to Moodle within minutes.
Book a demoFrequently asked questions
Why can't a student see their Moodle course after registering?
The usual reasons are timing and identity. The enrollment sync may run only overnight, the student's Moodle account may not exist yet because accounts are created separately, or the student is matched on a different identifier than the one in the SIS. Check the sync schedule, confirm the account exists with the right ID number, then look for the enrollment in the course's participants list.
What is the difference between unenrolling and suspending a student in Moodle?
A suspended enrollment keeps the student in the course but blocks their access, and their grades, submissions and group memberships stay intact. Unenrolling removes the enrollment entirely, along with role assignments and group memberships, and their grades disappear from the gradebook. During add/drop, suspending is safer, because a mistaken drop can be reversed without losing anything.
How often should Moodle sync enrollments from the SIS during add/drop?
Often enough that a student who registers in the morning can work in the course the same day. In practice that means within minutes during the add/drop weeks, rather than a nightly batch. After the deadline, changes slow down and a less frequent schedule is usually fine, as long as drops are still processed promptly and reconciled against the SIS.
How does Classeo handle late registrations and drops?
Classeo syncs enrollments from the SIS in real time or on a schedule, so adds, drops and section swaps reach Moodle within minutes. Section changes in meta-courses follow the SIS, and every enrollment change is timestamped and attributed, so the helpdesk can see what happened to a student without searching server logs. Monitoring and exceptions usually take under four hours a term.