Course Enrollments

This guide explains how to manage who is enrolled in a course in EmbayLMS — from the course editor’s Enrollments tab and from an individual user’s profile. It covers manual enrollment (single and bulk), unenrollment (dropping a learner), upgrading an in-progress learner to the latest course version, and automatic enrollment rules.

Prerequisites

• Role: Admin or Manager (manager scope is limited to their own team)
• The enrollment:create permission to enroll, and enrollment:delete to unenroll
• For enrollment, the target course must be Published (you cannot enroll learners into a Draft course)

Where enrollments are managed

There are two entry points, and they share the same underlying rules:

Every enroll, unenroll, and upgrade action is permission-checked and written to the audit log.

The course Enrollments tab

Open a course from Courses, then click the Enrollments tab. The tab lists every enrollment for the course with:

• Search by learner name or email
• Filter by status (active / in-progress, completed, dropped) and by course version
• Pagination — the roster is paginated (default 50 per page)

From here you can enroll users, unenroll a learner, and run version upgrades.

Manually enroll users

Enroll a single user

1. Open the course’s Enrollments tab.
2. Click Enroll users.
3. In People to enroll, type at least two characters of the person’s name (or email), then pick them from the list with a click or the arrow keys and Enter.
4. Click Enroll.

Only active people who are not already enrolled in this course are offered, so the list never suggests someone the enroll would skip. A group admin sees only the members of the groups they administer.

The learner is enrolled immediately and appears in the roster with an active status.

Enroll many users at once (bulk)

1. On the Enrollments tab, click Enroll users.
2. In People to enroll, search and pick each person in turn. Every pick becomes a chip above the field; remove one with its × button (or Backspace in the empty field). You can pick up to 500 people in one batch.
3. Click Enroll.

Bulk enrollment runs the same guards as a single enrollment, per user — see Enrollment guards below. If one user cannot be enrolled (for example they are already enrolled), that user is reported and skipped, and the rest of the selection proceeds. After the run you see a summary of how many were enrolled and which were skipped, with the reason for each skip.

Enrollment guards applied on every enroll

Both single and bulk enrollment apply these checks for each user:

Enrollment windows (open / close dates)

A course can be open for enrollment only between two dates — an intake window for a cohort, a compliance course that stops accepting sign-ups after a deadline, or a seasonal offering.

Set the window

1. Open the course in Courses → Settings tab.
2. In the Enrollment settings panel, set Enrollment opens and/or Enrollment closes.
3. Either date can be left blank. Blank means “no bound in that direction”, so a course with neither set is always open — which is the default and the normal case.

What learners see

Outside the window the course stays in the catalog. Hiding it would leave a learner unable to find training they know exists, so instead the card and the course page say why:

The last row matters: the window governs joining, not access. A learner who enrolled while the window was open keeps working through the course after it closes, and their completion and certificate are unaffected.

The window is enforced on the server

The badge is an affordance; the refusal is in the enrollment procedure itself, so it applies to every path — learner self-enrollment, admin single and bulk enroll, and automatic enrollment rules. An admin who needs to place someone outside the window changes the dates (or clears them), which is audit-logged like any other course setting change.

Boundaries are inclusive: a course opening at 09:00 is enrollable at exactly 09:00, and one closing at 17:00 is still enrollable at exactly 17:00.

Due dates

A due date is what makes an assignment a deadline rather than a suggestion. It drives three things on its own:

• the due-soon reminder the learner gets a few days before (the lead time is a platform setting),
• the overdue reminder if the date passes with the course unfinished, and
• the overdue escalation digest their manager receives, which repeats while the assignment stays overdue.

Until now a due date could only arrive by CSV import, the REST API or a recurring assignment — so a course you assigned by hand had no deadline and none of the three ever fired for it.

Set one while enrolling

The Due date field is optional and appears on every enroll path:

The group case is worth stating plainly: the date is stored on the assignment, so a late arrival inherits the same deadline everybody else was given rather than landing with none.

Change or clear one afterwards

The Due column on the course Enrollments tab and on a user’s enrollment list shows the date, flags it when it has passed, and edits in place:

1. Click Set (no date yet) or Change.
2. Pick a date and click Save — or click Clear the due date to remove it.

Every change is audit-logged with the old and new dates. Completed and dropped enrollments show their date but cannot be edited.

Moving a date re-arms the reminders

Each reminder is sent at most once per enrollment per phase, so changing a due date resets those markers. That is deliberate and it cuts both ways:

• a learner who was already reminded about the old deadline will be reminded about the new one, and
• they will not get a second copy of the same reminder for the same deadline, because the marker is only cleared when the date actually changes. Re-saving the same date does nothing at all.

The manager digest is re-armed too: a moved deadline is news for the manager as much as for the learner.

A date is a calendar day

The picker takes a day, not a time, and the day is stored as midnight UTC. A deadline of the 30th means the 30th everywhere, rather than the 29th for anyone west of Greenwich.

Enrollment approval

A course can require a decision before anyone joins it. Turn on Require approval in the course’s Settings tab → Enrollment settings. From then on, a learner who enrolls themselves is parked as pending approval instead of being enrolled, and waits for someone to approve or deny the request.

Decide a request

There are two places to do it, and they do exactly the same thing:

1. One course at a time — open the course’s Enrollments tab and filter the status to pending approval. Each pending row shows Approve and Deny.
2. Everything at once — open Call to Action in the left menu and go to its Enrollment Requests section. It lists every request waiting for a decision across all courses, oldest first, with the learner, the course, who asked, and when. (The old /admin/enrollment-requests address still works and lands on that section.) While anything waits on you, the menu item shows how many, for example Call to Action (3).

In the Enrollment Requests section you can also tick several rows and use Approve {n} selected to approve them in one action.

What each decision does

Both decisions are written to the audit log with the before/after status, and the Deny reason is stored on the record as well as sent to the learner.

The deny reason

Denying opens a dialog with an optional Reason box (up to 500 characters). It is worth filling in: it is the only thing the denial message can tell the learner beyond “not approved”, it is shown to them verbatim, and it is kept in the audit log. Leave it blank and they simply see that the request was not approved.

Prerequisites are re-checked on approval

Approving runs the course’s prerequisites check again, against the learner’s record as it is now — not as it was when they asked. If they no longer meet a prerequisite the approval is refused and the request stays pending, so an approval can never place someone into a course they are not eligible for.

Who can decide a request

Deciding a request needs the enrollment:create permission, and the reviewer must also be able to act on that learner and that course:

The queue and the buttons apply the same rule, so the page never lists a request the Approve button would then refuse.

Approval and the other enrollment paths

Approval applies to the paths where someone is asking. An enrollment placed directly by an admin (single or bulk), by an automatic rule, by a CSV import, or by the REST API is also parked as pending on an approval-required course — it shows on this queue with Requested by naming the admin or the automatic rule rather than the learner.

Unenroll (drop) a learner

1. Open the course’s Enrollments tab (or the user’s Enrollment history).
2. Find the learner’s row.
3. Click Unenroll (drop) and confirm.

Unenrolling removes the learner’s active enrollment in the course. This requires the enrollment:delete permission and is audit-logged.

Dropping a learner does not delete historical completion records or certificates the learner already earned — those are preserved.

Upgrade an in-progress learner to the latest version

When you publish a new version of a course, learners who are mid-course stay on the version they started on. The Upgrade action moves an in-progress learner onto the latest published version so they continue on the current content. This is the per-user / per-course manual counterpart to the course-wide “force re-enrollment on version change” toggle.

Upgrade one learner

1. Open the course’s Enrollments tab (or the user’s Enrollment history).
2. Find an active (in-progress) learner whose enrollment is on an older version. An upgrade button showing the exact version transition (for example v3 → v4) appears on that row — it only renders when the learner is behind the latest published version.
3. Click the transition button and confirm.

Upgrade everyone outdated at once

1. On the course’s Enrollments tab, click Upgrade outdated (bulk).
2. Confirm. Every in-progress enrollment on an older version is moved to the latest published version in one operation.

What upgrade does — and what it never touches

Why only active enrollments? Upgrading recomputes progress against the new module set. Doing that to a completed enrollment would put a finished learner back into “in progress” and is never desirable, so completed enrollments (and their certificates) are deliberately excluded.

Automatic enrollment rules

Auto-enrollment rules enroll learners into the course automatically when they meet a condition — so you don’t have to enroll each person by hand. Rules are managed from the course’s Enrollments tab.

Add an auto-enrollment rule

1. Open the course’s Enrollments tab.
2. Open Automatic enrollment rules and click Add rule.
3. Choose a rule type and its target (see the reference below).
4. Click Save. Users who match the rule are enrolled automatically; the same enrollment guards apply.

Rule types

Auto-enrollment rules apply going forward — when a user becomes a group member, completes the source course, or matches the attribute. Remove a rule from the same panel to stop future auto-enrollments; it does not unenroll learners already enrolled by the rule.

Managing enrollments from a user’s profile

The same actions are available on a single learner’s record at Users → [user], in the Enrollment history table. The table is actionable when you hold the right permissions:

If the user lacks the permission, these actions are hidden.

Enroll a user from their profile — the course-structure tree picker

Clicking + Enroll in course opens a picker that shows your course folder structure with the published courses nested inside — not a flat search box.

1. On Users → [user], click + Enroll in course.
2. Browse the folder tree. Courses that are not in any folder appear under Unfiled.
3. Tick one or more course checkboxes, or tick a folder checkbox to select every course inside that folder (including its subfolders). A folder with only some of its courses selected shows an indeterminate (partial) state.
4. Courses the learner is already enrolled in are disabled and tagged Enrolled — they cannot be selected again.
5. The footer shows how many courses are selected. Click Enroll {count} to confirm.

Each selected course runs the same enrollment guards as a single enrollment. The run is partial-failure tolerant: if a course cannot be enrolled (for example a prerequisite is missing), it is skipped and the rest proceed. The confirmation message reports how many courses were enrolled and how many were skipped.

Configuration / field reference

Troubleshooting

Related guides

• Course Management — create, version, and publish courses
• User Management — roles, groups, and the permissions that gate enrollment actions
• Recurring assignments — schedule repeat enrollments for compliance courses

Need help? Contact your EmbayLMS onboarding team or open a support ticket.