In This Article:

A waitlist holds learners who want a seat in a section that is currently full. Genius CE & Enterprise supports two ways of running waitlists:

This article explains how the classic waitlist works today and how the updated waitlist works once it is enabled, so you can decide which fits your organization.

Note: It is enabled per organization. Contact Genius support to have it turned on. Until then, your organization uses the classic waitlist described in the next section.

Regardless of which waitlist your organization uses, learners are placed on a waitlist when a section has reached an enrollment limit. Three caps can cause this:

When a section is full, the catalog registration button changes so learners can add themselves to the waitlist instead of enrolling.

This is how waitlists behave for any organization that has not enabled the updated waitlist.

Joining: when a section is full, the catalog button reads Add to Waitlist. When a learner adds themselves, a notification email is sent to the organization's Support Email address (set in the Administration settings) so staff know someone is waiting. Learners are not emailed and are not offered a seat automatically.

Administrators review the waitlist from the Waiting List report on the Reports tab. You can also set up a report subscription that emails one or more recipients the current waitlist, including each learner's reason for being on it. The SQL query used for that subscription is published in the current Waitlists help center article and is available from Genius support.

From the Waiting List report, an administrator can override the waitlist — either enrolling a learner directly into the section or removing their request from the list — according to your organization's policies. In the classic waitlist, seats are filled by this manual decision, not automatically.

Once the updated waitlist is enabled for your organization, learners join the list for free and the system fills open seats automatically. Instead of paying upfront to hold a place, a learner only pays — if the section has a fee — at the point they accept an offered seat. Administrators get a live view of the queue and a full offer history on the section's detail page. The rest of this article describes that experience.

Note: The updated waitlist is enabled per organization. Contact Genius support to confirm whether it is turned on for yours.

Once a learner joins a section's waitlist, the system manages the rest. The queue is ordered by when each learner joined — first to join is first to be offered an open seat.

Capacity increases also trigger offers. If you raise a section's capacity — through section edit, a CSV import, a bulk edit, or the API — the system detects the newly open seats and offers them to waitlisted learners on its next check. An offer may take a few minutes to appear after a capacity change.

Expiry is automatic. The system checks for expired offers every few minutes, marks them expired, and cascades the seat to the next learner. The learner whose offer expired is emailed to let them know.

Waitlist behavior is controlled on the section's create/edit form using two settings:

Both settings are Yes/No choices. Charge Learners to Join Waitlist stays disabled until Enable Waiting List is set to Yes, so you cannot configure a charge for a queue that will never form.

Important: New sections currently default to Yes for both settings. Confirm both values match your intent each time you create a section, rather than assuming the waitlist is off by default.

Pay-when-offered vs. pay-upfront

The updated model is pay-when-offered: learners join the waitlist for free and only pay if and when they accept a seat offer for a paid section. This replaces the older approach where learners paid to hold a place in line. Set up the section's price as usual; the system collects payment at the point a learner accepts a paid offer, not when they join.

Important: Turning off Enable Waiting List on a section that already has people waiting means new learners can no longer join. Review the queue before changing waitlist settings on an active section.

Open the section's detail page to see its waitlist. The Waitlist Queue panel — a collapsible panel on the section detail page — lists everyone currently in the queue and their status. The list is read-only and shows 25 learners per page.

Each row shows:

Status reference

Statuses display in uppercase in the Waitlist Queue panel:

Note: Across the learner and administrator experience, turning down an offer is labeled Leave Waitlist rather than Decline.

The Waitlist Offer History panel — a second collapsible panel on the section detail page — shows every seat offer the section has issued, newest first. Because a single learner can be offered a seat more than once over time — for example if an earlier offer expired and the seat later came back around — the history lists each offer separately rather than only the latest.

Each offer shows the learner, when the offer was made, when it was set to expire, when the learner responded, the response, the resulting status, and a Payment Attempt reference for paid offers. The Waitlist Offer History panel is section-wide; it shows all offers for the section and is not filtered to an individual learner.

The offer history is read-only and is intended for monitoring and support — for answering questions like whether the queue is moving and why a particular learner was or was not enrolled.

If a free section's course requires administrator approval, the waitlist respects that approval step rather than bypassing it. When a learner accepts the offer, the system creates an approval request instead of enrolling them outright. The standard approval notification emails are sent, and the learner's dashboard shows an Approval Pending status until you approve or deny the request. These waitlist-sourced requests appear in your standard course-request review area alongside other approvals — no separate review screen is needed.

Important: Paid sections that also require approval are not supported by the waitlist offer flow in this release. A learner offered a paid seat on an approval-required section is sent to checkout, which does not handle approval, so they cannot complete enrollment. Avoid combining a per-seat fee with required approval on waitlist-enabled sections.

In this release, the Waitlist Queue and Waitlist Offer History panels are for visibility only. Administrators can see the queue and offer history but cannot act on the queue directly. The following are not yet available:

The automated offer, expiry, and cascade process handles day-to-day queue movement without administrator action.

It is possible to configure a subscription report that notifies one or more email addresses regarding who is currently on the waitlist. This functionality helps track waitlist statuses and understand the reasons behind each learner's placement on the waitlist.

To achieve this, you can utilize the following SQL query, which is designed to provide comprehensive information about the individuals on the waitlist and the reasons for their status:

SELECT

wl.waitinglistindex as ID, students.studentindex as SID, students.lastname+', '+students.firstname as Learner, courses.name as Course, lmsterms.name as Term, wl.Reason as Status, wl.startdate as [Start Date], users.lastname+', '+users.firstname as RequestedBy, wl.requestedon as RequestedOn,

Stuff((SELECT ', ' + aff.Name

FROM Affiliations aff

INNER JOIN StudentToAffiliation sa on sa.AffiliationIndex = aff.AffiliationIndex

WHERE sa.StudentIndex = students.StudentIndex

FOR XML PATH('')), 1, 2, '') School

from waitinglist wl

left join students on wl.studentindex = students.studentindex

left join sections on wl.SectionIndex = sections.SectionIndex

left join courses on (wl.courseindex = courses.courseindex OR sections.CourseIndex = courses.CourseIndex)

left join departments on courses.departmentindex = departments.departmentindex

left join lmsterms on wl.lmstermindex = lmsterms.lmstermindex

left join users on wl.requestedby = users.userindex

It is important to note that an Administrator can override the waitlist. This action can be performed from the Reports tab, specifically through the Waiting List report. The Administrator has the authority to either enroll a user directly into a course or remove their request from the waitlist entirely, depending on the circumstances and institutional policies.