Camp

Staff manage summer camp from Camp: weeks, registration mode (lottery or open), rosters, unpaid seats, and cancellations. Dollar amounts and day windows are configured in Club → Programs (Camp group — managers and admins can edit them there). Registration windows and prices for each camp sign-up live under the Registration & pricing tab (open a row to edit). Never hardcode them in member emails without checking the live values first.

The Needs payment list shows overdue registrations that need review. Open an invoice to check payment or use the roster to cancel a registration. Payments still processing and registrations without a due date are excluded, so an empty list does not establish that every camp invoice is paid.

Club → Programs lists every camp policy knob (deposit, refund day boundaries, unpaid-seat warn/release timers, lottery pay-by window, roster-email recipients, and related values). Save from that page. Changes apply to new registrations and future cancellations. Amounts already frozen on a registration or invoice stay as written. This is the only place to edit camp rules and prices — the Camp page links there instead of editing them inline.

Create one week at a time (dates, capacity, pricing). Open registration when you are ready; close or cancel a week when needed. Roster export and check-in live on the Camp page tabs.

Week and roster links open another view. Compact buttons change a week, registration, attendance mark, or waitlist position. Closing registration, transferring a camper, and offering a spot keep their confirmation prompts. Cancellation, refund, archive, and delete remain distinct actions with their existing warnings and required details.

Cancelling a whole week is not the same as an individual cancellation. Closing registration and cancelling every live registration on that week refunds each household 100% of what they paid — no deposit withheld, no cash-refund fee, and the tiered refund schedule doesn't apply. Don't quote a family the individual tiered-cancellation numbers if staff are cancelling the entire week.

There's no direct "register a swimmer" action on the Camp page. Staff work a week through cancel, transfer, intake, and attendance. Registrations themselves come from the portal, the lottery, or the waitlist.

Intake is the safety-critical data on each registration — emergency contact, allergies/medical notes (including an anaphylaxis flag), and authorized pickup contacts. Members no longer type this into the camp form for every registration: it now lives once on the household profile, is shown read-only during registration, and is frozen onto the registration as a snapshot at submit time. So the roster reflects what the profile said when the family registered, and a later Household edit only flows into their next registration — it never rewrites a settled one. Staff can still correct a registration's intake directly from the roster's Edit intake action (that panel edits the per-registration free-text fields and the structured per-dependent allergy/pickup lists together). Because members now enter it once and reuse it, the portal also runs a pre-registration Camp checkup and makes an emergency contact a hard requirement — see below. See Camp roster safety data for what's captured and how staff should read it.

Emergency contact is a hard block for members. A household with no emergency contact (name + phone) on its profile cannot register for camp — the portal refuses with "Add an emergency contact on the Household page before registering for camp," and a multi-child registration is checked up front so one missing contact blocks the whole batch. The portal's Camp checkup card flags this (and any missing camper waiver, signable right there) before a parent starts. If a member says camp won't let them register, check for a missing emergency contact or unsigned waiver first. Members see participants called campers throughout the portal; the admin roster still labels the column "swimmer."

A counselor roster email fires automatically from the daily scheduled process exactly 2 days before each week starts. It sends at most once per week. If no roster-email recipient addresses are configured for the org, the send is skipped silently and never retried, with no error surfaced to staff. If counselors say they never got a roster, check Club → Programs (Camp group) for roster-email addresses before assuming the cron failed.

Deleting a week is only allowed when it has zero registrations and zero waitlist history; any history on the week forces archive or cancel instead, and both delete and archive require typing an exact confirmation phrase before they take effect. Don't be surprised when delete is blocked or when the system asks you to type a confirmation string. That's expected.

The unpaid-seat release sweep ships off by default and must be turned on explicitly from the Camp page. See Refunds and credits below for what it actually does once enabled.

When lottery mode is on for a season:

1. Households submit ranked week requests during a request window (not a refresh race).

2. The draw allocates seats; winners get invoices with a pay-by deadline (configured in Settings, default 7 days from the draw. Not due the same day).

3. Unpaid seats can release to the waitlist after warn/release timers (configured in Settings). But only once the sweep is turned on; see Refunds and credits for the release mechanics and safeguards.

4. Losers land on the waitlist in draw order; freed seats auto-offer down the list.

Sibling "must be together" requests are honored at the draw: a group is granted a week only if the whole group fits, and a group that can't be fully seated is marked lost together, never split. See Camp lottery for the full mechanics.

That togetherness guarantee also carries through to the waitlist-offer stage: when a seat frees up on a week with a together-group waiting, the sweep offers the whole group at once (every sibling gets their own offer) only when the freed capacity covers the entire group. Otherwise it skips the group without losing its position and tries the next entry. Each sibling still has to accept their own offer individually within its expiry window, so one sibling can still end up seated while another's offer lapses unaccepted. That's an acceptance-timing outcome, not a togetherness bug. See Camp and event waitlists for the full offer mechanics.

Leftover capacity can open to ordinary first-come registration.

Moving a swimmer to a different week settles the price difference against the household's whole position, not just the original invoice:

• Moving to a cheaper week voids any open invoice for the old week and reissues a smaller replacement invoice. Unpaid debt is erased first. Only money already paid in excess of the new price becomes credit.

• Moving to a dearer week opens a new top-up invoice for the difference.

• Refund boundaries (deposit, full/partial-credit windows) can only get tighter on a transfer, never looser. A transfer can't hand a family a better cancellation deal than they'd have had by cancelling and rebooking.

Camp waitlist offers expire after a short clock (configured in Settings). Accepting an offer creates a registration and invoice like a normal seat. But the offer itself does not hold the seat. Accepting re-checks capacity live, so on rare occasions a household can click accept and still lose the seat to a faster staff registration that lands in the same moment. If that happens, apologize and re-offer the next opening; it isn't a bug.

Note: sending an offer always emails the household, and since #350 letting an offer lapse unaccepted emails them too ("Your waitlist offer has expired"). That expiry email is best-effort — a delivery failure is logged, not retried — so if a member insists they never heard back, still check the entry's status (offered / expired / waiting) rather than relying on the email alone.

Camp shares its waitlist implementation with events. Same queue, offer, and expiry mechanics. For the admin Remove and Promote/Offer next spot actions, and the full FIFO/sweep behavior, see Camp and event waitlists.

Cancellation policy is frozen on each registration at booking time. Broadly:

• Deposit: non-refundable portion (configured in Settings).

• Tiered credit: full / partial / none based on how many days before the week starts (configured in Settings).

• Lottery wins: credit may also wait until the waitlist refills the seat (backfill gate).

• An ordinary (non-lottery) camp cancellation credit is a normal account credit. It can be applied to dues and doesn't expire. Only a lottery-seat cancellation's backfill-gated credit is camp-scoped (it cannot pay dues) and expires at a window configured in Settings (default: end of the following season). See the credit on the household for the actual terms.

• Registrations from before the tiered refund schedule existed are exempt for life. If a registration predates the tiered policy, it permanently keeps the old binary rule (full credit or no credit, no partial tier) with an uncapped cash refund instead of the fee-capped tiered payout. If a refund number for an old registration looks different from what Settings would predict today, this is why. It isn't a calculation bug.

The cancel button checks its own number. Each cancel and refund button on the roster carries the figure it showed you. If that figure has changed by the time you click — a refund-window boundary passed while the tab sat open, or a bank payment settled in the meantime — the cancellation is refused and asks you to reload. Reload, read the new quote, and cancel again if it is still right. Nothing is cancelled or refunded on a refused click.

Cash refunds through Stripe are staff-only: you must enter a reason, the amount is capped at the tier's share minus the cash-refund fee (configured in Settings), and the refund is refused with a specific error when the fee would eat the whole payout. That refusal is expected behavior for a small remaining balance. It isn't a bug to escalate. Prefer quoting the cancellation quote on the Camp roster before telling a parent a number.

If a staff-requested Stripe refund call fails after the cancellation has already gone through, the seat is still released and the waitlist still auto-advances — the cancellation itself is not undone. The failure is logged and the system tells you at the end that the refund needs to be finished manually. Don't assume a failed refund means the seat is still held; check the roster and finish the refund by hand (e.g. from Stripe directly or by re-attempting) so the household isn't left unpaid-out.

Unpaid-seat sweep

The automated release of unpaid camp seats to the waitlist is off by default. An admin has to turn it on explicitly from the Camp page before any seat is ever released, warn/release timers included. Once on:

• A warning email goes out first, and its lead time (configured in Settings) is always honored before release. Even for an already-overdue backlog the first time the sweep is turned on. Nothing releases instantly.

• Only seats behind a fully unpaid invoice are eligible. A part-paid unpaid seat is never auto-released; it's surfaced to staff for a human decision instead.

• The sweep only ever looks at invoices sitting in open status: never one that's processing (an ACH payment settling, which can take days). That's what protects a family who is mid-ACH-payment; if a member says their seat is at risk while ACH is still clearing, they're not "stuck," the sweep simply won't touch them until the payment resolves.

• A registration whose invoice has no due date at all (this can only happen on very old registrations that predate the sweep policy) is invisible to the sweep forever. It will never auto-release, no matter how overdue it looks. If an old unpaid seat never gets swept, that's expected; it needs a manual release.

Each swimmer must sign the current Camp waiver (per season) before registration or a lottery request. Publish it under Agreements. If no version is published, camp has no signature gate.

The member Camp checkup separates Household information from Camp waivers. Open a camper's Read and sign row to read the full waiver, check the agreement box, and choose Sign waiver. Opening a row does not sign it. Check the season shown: one camper can have separate tasks for this season and next season. Each form signs only its listed person, agreement, and year. The agreement box must be checked before signing, including when signing as part of registration or saving lottery requests. If it was not checked, the page asks the member to confirm agreement and does not record a signature.

When a parent registers multiple children in one pass, each child is processed independently. One sibling's outcome never rolls back another's:

• A sibling who hits a full week is automatically queued onto that week's waitlist.

• A sibling missing a signed waiver is a hard failure: the parent is told to register that child separately once the waiver is signed.

This is why you'll sometimes see one sibling registered and the other not. It's the expected result of per-child processing, not a partial failure to fix.