Camp and event waitlists (program waitlists)

This covers the shared queue mechanics behind camp week and event waitlists. It is a separate system from the membership waitlist. Different code, different admin screens, different rules.

Camp weeks and events share one tokenized, FIFO waitlist queue. A household can only join a program's waitlist once that program is full for the seats/party size requested. If there's room, joining routes back to normal registration instead.

An hourly scheduled process sweep is the safety net: for each program with a waiting entry, it offers a spot only to the entry at the front of the line, and it skips any program that already has a pending offer outstanding. For events, the sweep also checks that the head entry's party size actually fits the free capacity: it will not skip ahead to a smaller party behind them.

Staff can also send an offer directly from the console, out of turn:

1. Open Camp (roster tab for the week) or Events (the event's waitlist tab).

2. On Events, every waiting row shows a Promote action. You can target any entry, not just the one at the front.

3. On Camp, the Offer next spot action is shown only for the entry currently at the front of that week's queue.

4. Confirm the prompt (it tells you the regular price applies if they accept) and the offer email/token goes out immediately.

Both buttons call the same underlying offer function as the automatic sweep: the FIFO guarantee described above only holds for the automatic sweep. A staff-initiated promote is a deliberate way to jump the line; use it when you have a reason to (e.g. a manual accommodation), not as a routine substitute for letting the sweep run.

The number in the # column is the household's place in line among the live entries, counted 1, 2, 3 with no gaps. It is not a fixed ticket number: when someone ahead leaves or accepts, everyone behind moves up one. The portal shows a member their place counted among households still waiting, so while an offer is out to someone ahead of them the member may see a number one lower than you do. Both are right.

The up and down arrows move an entry one place from where the table showed it. If a colleague has changed the order since your page loaded, the move is refused with This waitlist changed since the page loaded, so the move was not made — reload, look at the new order, and try again.

A household can hold only one live offer at a time. Clicking Promote or Offer next spot on an entry that already has an offer out is refused, and so is an offer that lands at the same moment the household leaves the list.

Sending an offer does not reserve capacity. When a member accepts, the system re-checks capacity and freezes the current price onto the invoice at accept time, not offer time. If the seat or spot was retaken in the meantime (for example, by a direct registration), the entry reverts to waiting — its position is untouched — and the member is told they're "still at the front of the line."

That message is accurate when the sweep offered to the genuine head of the queue. It can read as misleading after a staff Promote/Offer next spot on a non-head entry that then falls through to re-waiting, since that entry may not actually be at the front. Keep that in mind if a member questions their position after an out-of-order offer that didn't stick.

Each offer has an expiry window (configured in Settings. Separate settings for camp/event offers vs. lap-slot offers). When the window passes without a response, an hourly scheduled process sweep flips the offer and its waitlist entry to expired and moves the spot to the next household in line. Since ticket #350, that sweep also emails the household at the moment it expires their offer, for camp, event, and lap waitlists alike, so a lapsed offer is no longer silent (matching how the membership waitlist has worked since #268). If a member says an offer expired and they were never told, check the entry's status on the program's waitlist tab first; an undelivered notification is a transport/delivery issue, not an expected gap.

If the camp week requires a signed waiver and a household accepts a waitlist offer, the accept flow routes through a sign-and-accept step in the same action: the member signs the current waiver and the acceptance completes in one submission. No separate waiver step is needed before or after.

• Removing a single household: use Remove on their waitlist row (Camp roster tab or Events waitlist tab). This revokes any pending offer for that entry and immediately auto-advances the queue so the next household isn't stuck behind a dead offer.

• Canceling or closing an entire week or event revokes every pending offer on that program's waitlist, marks every live entry removed, and emails every affected household.

Camp lottery requests can mark siblings as a group that must be seated together, and that guarantee carries through past the draw and onto the camp waitlist: when a seat frees up on a week that has a together-group waiting, the sweep offers the whole group at once, every sibling gets their own offer/token, only when the freed capacity covers the entire group. If it doesn't fit yet, the sweep skips the whole group (its queue position is kept, and the skip is logged for staff) and tries the next waiting entry instead: the same all-or-none rule the lottery draw uses. Event waitlists have no grouping concept.

One thing this doesn't guarantee: once offers go out, each sibling still has to accept their own offer individually within its expiry window. The platform doesn't force a joint accept. If a parent reports one sibling got a seat and the other didn't, check the offer history first. A missed or expired individual offer, not a togetherness failure, is the most likely explanation.