In This Article:

• Overview
• How Learners Are Placed on a Waitlist
• The Classic Waitlist
• The Updated Waitlist
• Automated Offer Process
• Setting Up a Waitlist
• Viewing the Waitlist Queue
• Viewing Offer History
• Sections that Require Approval
• Queue View Capabilities
• Subscription Report of Waitlist
• Troubleshooting
• Best Practices

Overview

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

• The classic waitlist (the default today): learners are added to a list when a section is full, and an administrator decides who to enroll, working from the Waiting List report.
• The updated waitlist (available on request): learners join the list for free, and when a seat opens the system automatically offers it to the next learner in line, gives them a fixed window to claim it, and gives administrators a live view of the queue and offer history.

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.

How Learners Are Placed on a Waitlist

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:

• Section cap: the maximum number of learners allowed in a given section. Set on the section, with a default in the Administration settings.
• Instructor cap: the maximum number of learners allowed across sections taught by a specific instructor. Set on the instructor, with a default in the Administration settings.
• Affiliation cap: the maximum number of learners from a particular affiliation allowed in a section, so no single affiliation takes all the seats. Set in the Administration settings.

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

The Classic Waitlist (Default Today)

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.

Seeing who is on the waitlist

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.

Enrolling or removing a waitlisted learner

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.

The Updated Waitlist (Available On Request)

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.

The Automated Offer Process

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.

1. A seat opens. This happens when an enrolled learner drops or is removed, or when you increase the section's capacity.
2. The next learner is offered the seat. The system creates a seat offer for the learner at the front of the queue and emails them a link to claim it.
3. The learner has 24 hours to respond. They can accept (and pay, if the section has a fee) or leave the waitlist.
4. If they accept, they are enrolled. For paid sections, enrollment completes once payment succeeds.
5. If they decline or let the offer expire, the seat automatically passes to the next learner in line.

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.

Setting Up a Waitlist

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.

Viewing the Waitlist Queue

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.

Viewing Offer History

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.

Sections that Require Approval

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.

Queue View Capabilities

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:

• Manually reordering the queue, forcing an offer to a specific learner, or removing a learner from the queue.
• Manually expiring or re-issuing a single offer.
• Cross-section or organization-wide offer reports and analytics.

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

Subscription Report of Waitlist

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.

Troubleshooting

Best practices

• Decide on the waitlist model before publishing a section: free-to-join with pay-when-offered is the default and the recommended approach for most paid sections.
• Set the section price correctly before enabling the waitlist, since that price is what learners are charged when they accept a paid offer.
• Use the Waitlist Offer History panel when a learner asks why they were not enrolled — it shows exactly when each offer was made, when it expired, and how the learner responded.
• When you increase capacity to admit waitlisted learners, allow a few minutes for offers to go out, and check the Waitlist tab to confirm the queue is moving.
• For sections that require approval, monitor your course-request review area, since waitlist accepts on those sections create approval requests rather than immediate enrollments.