Skip to main content
The waitlist puts new registrations into a queue attached to the local center they signed up for, instead of letting them straight into the platform. Each person gets a position, a status link they can bookmark, and an email when things change. Chapter staff work the queue and admit people when there is room. Built for organisations whose local groups have real capacity limits: scout troops, sports clubs, chapters with a room and a leader-to-member ratio. Replaces a spreadsheet of names per branch and the emails asking “where am I on the list?”.
The waitlist is per local center, and it applies to every new self-registration for a center, not only to overflow. While it is on, someone who registers for a center is queued whether that center is full or not. Their account status becomes Waiting list and they cannot sign in until an administrator approves them and sets their status to Active. Organisation administrators are exempt.

​
Turning it on

Settings → Users & Profiles → Registration Waitlist. Requires ADMIN_TENANT. The entry is in the menu whether or not the waitlist is on, and every setting below lives on that page, starting with the switch that enables it. Registration Waitlist settings with the enable switch, Allow Self Removal, Notify Admins On New, Volunteer Trigger Slots and per user type priority levels Below those, Waitlist Priority Settings assigns each user type a priority of Normal, High or Emergency, which anyone joining the queue picks up. Saving these requires HR_TENANT, and Reset to Default puts every type back to Normal. Capacity per local center. Each center’s capacities live in its own Waitlist Settings (/local/settings/waitlist), reachable with FINANCIAL_LOCAL: enable the user types the center accepts, give each a Maximum Capacity, and the page shows the current count and available spots. Capacity is a planning figure, not a barrier. It drives the “spots available” readouts and the volunteer slot mechanism; it does not stop people joining the queue.

​
What a new registration experiences

1

They register as usual

Nothing about the form changes, including the local center choice. A registration that does not name a local center is never queued: there is no queue to join, so it follows your normal registration rules instead.
2

They confirm their email address

This is the moment the entry is created, not the moment they submit the form. Their account status becomes Waiting list, the entry goes to the back of that center’s queue, and the confirmation screen shows their position and estimated processing date.
3

They get the confirmation email

It repeats the position and estimated wait and links to a status page that needs no login, so it can be bookmarked and shared. For a child registered by a parent, this and every later waitlist email goes to the parent who owns the family instead of to the child.
4

Staff approve the entry

The entry moves to Approved, the queue behind them is renumbered, and the person gets an approval email pointing at the dashboard.
5

You set their account status to Active

Approval does not do this for you. Until you change the status from Waiting list to Active in the member directory, the person has an approval email in their inbox and still cannot sign in. This is the single most common complaint the waitlist generates.

​
Children and the minimum age

If your organisation has a minimum registration age and a parent registers a child below it, the entry gets the Underage status rather than Waiting: hidden from the waitlist screen unless you filter for it, and not offered to the bulk approve, reject or priority actions, which only act on Waiting entries.
Orgo ships a job that promotes those children when they reach the minimum age, flipping the entry to Waiting, giving it a position at the back of the queue and emailing the parent. That job is not currently scheduled, so nothing happens automatically on the birthday. Until it is, review the Underage filter yourself and move children into the queue when they become eligible.
The minimum age is stored per organisation but there is no control for it in the settings interface at the moment. Ask support to set it if you need it.

​
What priority actually does

Priority does not move anyone up the queue. Positions are assigned strictly in order of joining, per local center, and renumbered when entries leave. What it changes is the estimated wait shown to the person, calculated at half the normal estimate for High and 30% of it for Emergency, and the priority filter staff use to decide who to admit first. Priority comes from the person’s user type and can be changed for selected entries at any time. One special case: if the person registering a child is an active volunteer anywhere in the organisation, the child’s entry is created at High priority regardless of user type.
The table does group entries by priority before position, but not in the order you would expect: with priorities mixed, Normal entries come first and Emergency ones last. Use the priority filter to find your urgent cases rather than reading the top of the list.

​
Working the queue

Waitlist in the main menu (/waitlist) needs ADMIN_LOCAL to open; the bulk actions themselves check HR_LOCAL. What you see is scoped to your permissions: ADMIN_TENANT sees every center, HR_PARENT_LOCAL its anchor center and every center beneath it at any depth, ADMIN_LOCAL or HR_ASSISTANT_LOCAL only their own. The bulk actions apply that same scope entry by entry, not once at the door: an entry in a center you do not cover is skipped rather than processed. You will not normally see that happen, because the list is already scoped before you can tick anything. Waitlist screen with local center, status and priority filters, bulk action bar, and a table of entries showing position, local center, user, priority, status, type and requested date Three filters sit at the top: local center, status (defaults to Waiting) and priority. Pick a single local center and you also get four tiles, Total Waiting, Processed Today, Avg Wait Time and High Priority, plus a capacity bar per user type showing count against capacity and spots left.
Total Waiting and Avg Wait Time are calculated from the queue. Processed Today and High Priority currently display 0 whatever the data: use the status and priority filters to count those instead.
The table pages 30 at a time: position, local center, the person with a link to their profile, priority, status, type (their user type, or Parent, Volunteer or Parent & Volunteer, with self registered or parent registered underneath) and the request date with days waited. Tick the entries you want, then use the action bar: Every action confirms first, and the counts in the confirmation reflect only the entries the action can actually process.
The toast after Approve Selected reads “undefined entries approved successfully”. The approvals themselves are fine: reload the list, or filter by status Approved, to see the real result.
Admitting a group of people end to end:
1

Filter to one local center

The tiles and the per user type capacity bars only appear once a single center is selected, and they are what tells you how much room you actually have.
2

Leave the status filter on Waiting

It is the default. Add the priority filter if you triage by priority, and remember that priority never reorders the queue: positions stay in joining order, so you are choosing to skip people, not being shown a reordered list.
3

Tick the entries and use Approve Selected

Confirm the dialog. Approved entries are stamped with who approved them and when, the queue behind them is renumbered, everyone approved is emailed, and volunteer slots are released if you configured them.
4

Set each person's account status to Active

In the member directory, not here. See User Statuses.

​
The status page

Every waitlist email links to a public status page at /waitlist/status/<code>. It needs no login and shows the person’s name, local center, queue position, status, estimated wait, priority, when they registered, how many people are ahead and what happens next. Approved and rejected entries show the outcome instead, with the rejection reason if there is one. Estimated wait is a projection from how quickly that center has been processing entries, adjusted for priority, with a buffer. Treat it as an indication, not a promise.

​
Entry statuses

​
Common scenarios

Approval marks the queue entry and emails the person. It does not touch the account, so their status is still Waiting list, and Waiting list blocks the sign-in exactly as Suspended does.Change the status to Active in the member directory. If you approve in batches, make the status change part of the same routine, because nothing in the interface will remind you and the person’s own view of it is an approval email followed by a refused login. See User Statuses.
Work through the four filters that hide people, in this order.
  1. Status. It defaults to Waiting, so anyone already approved, rejected or withdrawn is out of view.
  2. Underage. Children below the minimum registration age are only listed when you filter for Underage specifically.
  3. Local center. The list is scoped by the center filter and by your own permissions: ADMIN_LOCAL sees only their own center, HR_PARENT_LOCAL its anchor center and every center beneath it at any depth, ADMIN_TENANT everything.
  4. Whether they were ever queued. Someone who registered without choosing a local center is never queued, and neither is anyone with organisation-wide admin rights. Registrations from before you switched the waitlist on are not queued retroactively either.
If they are missing from all views, they are a normal member: check the member directory instead.
Not from the interface. Enable Registration Waitlist is one switch for the whole organisation, and while it is on every registration that names a local center is queued, full center or not.A per-center opt-out does exist in the underlying data, but no screen and no API field writes it, so it is not something you can configure yourself.The practical options are to leave the waitlist off and control intake with Manual Approval instead, which reviews everyone without queueing them, or to turn the waitlist on and admit the unconstrained centers’ queues promptly so the delay for them stays close to zero. Setting a generous Maximum Capacity for those centers does not help: capacity is a planning figure that feeds the readouts, not a gate.
Prune it in one pass rather than entry by entry.
  1. Sort by the Requested column so the oldest surface first, and use the days-waited figure under each date to decide your cut-off.
  2. Select that block and Export CSV if you want a record before you change anything. The export is built from the rows currently on screen, so export page by page rather than expecting one file for the whole queue.
  3. Send Notifications to the same selection. Everyone gets their current position and how many people are ahead, which is usually enough for the people who have moved on to reply or ignore it.
  4. Reject Selected for the ones you are closing. The reason is required and is emailed to them, so write it for the person reading it, not for your records.
Rejected entries stay in the data with their reason and are visible under the Rejected status filter, so this is reversible in the sense that you can see what you did, though the person has to register again.
Notify Admins On New is off by default, so check that first.When it is on, the email goes to a narrower group than most people expect: active members whose own local center is the center that was joined, and whose permissions include HR_LOCAL directly. An admin who covers that center through a role, or a tenant-level admin who is not assigned to the center, is not on the list.The link in that email points at a page that does not exist. Open the queue from Waitlist in the main menu instead.
They do, whatever the data, because those two tiles are not wired to anything the statistics endpoint returns. Total Waiting and Avg Wait Time are real.Use the status filter to count what was processed and the priority filter to count High entries. The tiles also need HR_LOCAL, so an ADMIN_LOCAL without it sees the table but no tiles at all.
The Waitlist Settings page under local settings always edits the local center of the person opening it, so it needs FINANCIAL_LOCAL and a local center on your own account. An administrator with no local center is bounced straight back with “You need to be assigned to a local center”, and there is no center picker on that screen: to set capacities for several centers, an admin in each one has to do it.
The waitlist queues people per local center with a visible position, an estimated wait, a public status page and its own emails. Manual Approval parks new registrations as Unapproved for review, with no ordering and no capacity view.Use the waitlist when place scarcity is the problem, Manual Approval when vetting is.You can have both on. Queueing wins: a registration that names a local center goes to Waiting list and Manual Approval never sees it, so it is you setting the status to Active after approval that admits them. Manual Approval still governs registrations with no local center, which the waitlist never touches.