Applications, requests & waitlists

Sometimes you don’t want to add people to a program directly — you want them to ask, and you decide who gets in. This page covers where those requests land, how you decide them, and what happens once a program runs out of seats.

What this does

A program whose access is Restricted can’t be joined directly. A learner who opens it sees Request access, answers a single question — Why do you need access? — and chooses Send request. The reason is required. That request lands in your Requests inbox, and you approve or reject it from the program.

Separately, when a program hits its seat limit, people are queued on a waiting list instead of being enrolled. You release seats from that queue by offering them.

This suits a company vetting applicants for a leadership track, a university managing an oversubscribed course, a school placing students in a limited elective, or a SaaS academy gating a certification cohort.

What produces a request

Two things, and only two:

Restricted access mode. Set on the program’s Who can join tab. This is the self-serve lever, and it is the usual one.
An approval, consent, or payment requirement configured for your organization by Lurno. These are enforced everywhere — pushed enrollments come back as “Need approval”, “Need consent”, or “Need payment” — but they are not editable from the interface.

There is no application-form builder. What a requester submits is a single free-text reason, not a questionnaire you design.

Work the Requests inbox

Go to Enrollment → Requests. The page lists join requests and waiting-list entries together, newest first.
Filter with the buttons across the top: All, Join, Waiting, Permission. Each carries a count. Permission is always empty for now — that feed hasn’t shipped, and the view says so.
Each row shows a Join request or Waiting list badge, the program name, how long ago it arrived, and a shortened reference for the person. Names aren’t resolved in this view — open the program to see who it is.
Choose Review on a join request, or Open program on a waiting-list entry. Both take you to the program, where the decision is actually made. (The small unlabelled button beside Review goes to the same place — it does not reject anything.)

The inbox is a triage list — it points at work, it doesn’t decide it.

Decide a join request

On the program, open the Join requests tab. The buttons on each row depend on where the request has got to:

Request state	Buttons shown	What actually works
Submitted	Start review · Approve · Reject	Only Start review. Approve and Reject are refused until the request is under review.
Under review	Approve · Reject · Waitlist	All three.
Waitlisted	Offer seat · Reject	Neither. Offer seat is refused because this row doesn’t carry a seat-offer expiry; Reject is refused because the platform only allows rejecting a request that’s still under review. A Waitlisted request has no working action in this tab.

So the reliable path is: Start review, then Approve, Reject, or Waitlist. Treat Waitlist as a one-way door for now — once a request lands there, nothing in this tab can move it further.

Each action opens a confirmation dialog and notes that it will be recorded in the application history. Approving admits the person and creates their enrollment straight away — it does not check the program’s Max seats, so approve deliberately on a full program. Waitlist records the decision on the request itself, but — unlike the seat-holding waiting list below — it doesn’t queue the person for a seat offer.

Work the waiting list

Open the program’s Waiting list tab. Entries are ordered by priority, then by when they arrived, and each shows its state and priority.

Offer seat holds a seat for that person, by default for 48 hours. Once offered, the row shows when the offer expires and the button disappears.
Withdraw takes someone off the list entirely.

This is the only place where offering a seat works — the identically-named button on a waitlisted join request doesn’t go through.

The person accepts or declines the offer themselves, from their own offers page. An offer that isn’t accepted before it expires releases the seat again.

Promotion is manual by default: you decide who gets the next seat. Fully automatic first-in-first-out promotion exists in the platform but is configured by Lurno per program, not by you — if it isn’t set up, no one is promoted without you offering the seat.

Reserve seats for an owner

The Seat reservations tab on a program pre-allocates part of the total to a named owner. Choose Add quota to open the Reserve seats dialog, pick the owner type and owner, set Reserved seats, tick Allow overbooking if used seats may exceed reserved, then choose Reserve.

The owner-type list offers group, customer, audience, organization, and sponsor — but only two are usable today. Organization fills itself in with your current organization, and Group gives you a picker of the org’s groups. The other three show “picker ships when that module is available” and can’t be saved.

Each row shows the owner, used-of-reserved seats, and an Overbooking badge when it’s allowed. Reservations can be edited later; one with seats already used can’t be deleted.

This is different from the program’s overall Max seats, which is fixed when the program’s enrollment or an extra cohort is created.

Reference

Control	Where it lives	What it controls
Access mode	Program → Who can join → Change	Restricted is what makes people request access rather than join
Requests inbox filters	Enrollment → Requests	All · Join · Waiting · Permission
Request actions	Program → Join requests	Start review, then Approve, Reject, or Waitlist
Waiting-list actions	Program → Waiting list	Offer seat (48-hour default), Withdraw
Seat reservations	Program → Seat reservations	Reserved seats per owner (organization or group), and whether overbooking is allowed

Note: “programs” and “enrollment” may be renamed in your organization. See Terminology.

Troubleshooting

The Requests inbox has rows but no Approve button. Decisions are made on the program, not in the inbox — use Review to get there. If a row shows no buttons at all, you’re missing the permission for that kind of row: Review enrollment applications for join requests, Manage individual enrollments for waiting-list entries.

The buttons on the program show, but the action fails. Two causes. First, the program’s own tabs draw every button regardless of your permissions, so a missing permission surfaces as “Action failed” only after you confirm. Second, some buttons are shown in states the platform doesn’t accept — Approve and Reject on a request you haven’t started reviewing, and both Offer seat and Reject on a request that’s already Waitlisted (that state has no working action in this tab). Use Start review first on a fresh request, and work seat offers from the Waiting list tab instead.

No requests are coming in. The program probably isn’t restricted. Check its Who can join tab: public and organization-wide programs let people join outright, so nothing reaches you for a decision.

The Permission filter is always empty. That’s expected. The consent feed isn’t surfaced yet, and the empty state says so.

Approve failed and the request went back to where it was. Approval creates the enrollment in the same step, so if that creation is refused the whole approval is rolled back. The usual cause is your organization’s subscription cap on active enrollments. See Billing & plans.

Approving pushed the program over its seat limit. Approval enrols the person outright rather than checking Max seats — only enrollments pushed through the Add people wizard are diverted to the waiting list when a program is full. Check the seat count on the program before you approve a batch.

Nobody is being promoted when seats free up. Automatic promotion isn’t on for that program — it isn’t a setting you can switch on. Offer the seat yourself from the Waiting list tab.

An offered seat went back to the queue. Seat offers expire. The person didn’t accept in time; offer it again or move to the next person.