/ to search
Documentation Events

Events

How to Manage Event Waitlists

Use this guide when your team needs to set up an event waitlist, understand what will happen when the event fills up, and manage waitlisted registrations from the dashboard.

Before you begin

Waitlists only help when the event has a real capacity limit. If Capacity is blank or 0, the event is treated as unlimited and waitlist settings will not meaningfully change the public registration flow.

What This Helps You Do

This page helps you:

  • turn on a waitlist for an event
  • choose the right waitlist mode
  • test what supporters will see when the event is full
  • manage waitlisted registrations and offers from the Filament dashboard

Before You Start

Before you enable the waitlist, confirm:

  • the event has a Capacity greater than 0
  • your team understands whether this is a free event or a paid event
  • staff knows who will monitor the waitlist after the event fills up

This matters because the system behaves differently for free and paid registrations:

  • free registrations can follow the event's selected waitlist mode
  • paid registrations are forced into offer-based waitlist handling, even if the event is set to Manual or Automatic
Important

In the public registration flow, a paid waitlist registration does not automatically become confirmed. It must go through the offer-claim path first.

Step 1: Turn On Waitlisting in the Event

Open the event in the dashboard and go to the registration settings.

Review these fields together:

  • Capacity
  • Overbook seats (%)
  • Overbook seats (fixed)
  • Enable waitlist
  • Waitlist mode

Then:

  1. Set a Capacity greater than 0.
  2. Add any overbook buffer only if your team intentionally wants it.
  3. Turn on Enable waitlist.
  4. Choose the waitlist mode.
  5. Save the event.

The waitlist mode options are:

  • Manual (staff approves)
  • Offered (invite next person to claim)
  • Automatic (auto-promote next person)
Tip

Overbook seats affect the real seat limit the system uses. If an event seems to accept more registrations than expected, check the overbook fields before assuming the waitlist is broken.

Step 2: Choose the Right Waitlist Mode

Use Manual when staff wants hands-on control

Choose Manual when staff wants to review the list and decide what to do next.

In this mode:

  • new full-event signups are still placed on the waitlist
  • the system does not auto-confirm the next person
  • staff can manage waitlisted registrations from the dashboard
  • staff can manually create an offer from the registrations table or the Manage Waitlist page

This is often the safest choice for invite-sensitive events, donor cultivation events, or events where seat releases need staff review first.

Use Offered when the next person should get a claim window

Choose Offered when you want the next waitlisted registrant to receive a time-limited chance to claim the seat.

In this mode:

  • waitlisted people stay in waitlisted status until they claim
  • an active offer reserves capacity
  • the public claimant must use the same email address used to join the waitlist
  • expired or already-claimed offers stop working cleanly

This is especially useful for paid events, because the system uses offer-based handling for paid waitlist registrations anyway.

Use Automatic only when you want the system to promote the next person

Choose Automatic when staff is comfortable letting the system promote the oldest eligible waitlisted registration once a seat opens.

In this mode:

  • the event must have waitlist_enabled = true
  • the event must be in automatic mode
  • the event must have a capacity greater than 0
  • the next eligible waitlisted registration is chosen in oldest-first order

For free registrations, the system confirms the next person automatically.

For paid registrations, the automatic promotion moves the person into pending so they can complete payment.

Step 3: Understand What Happens When the Event Reaches Capacity

When a registration attempt would exceed the available seats:

  • the event is considered full for that attempt
  • if waitlisting is enabled, the registration can be created as waitlisted
  • the registration stores waitlist metadata, including the mode used at the time
  • a waitlist email is queued

The seat calculation is not just "confirmed registrations."

The event's current seat usage also includes:

  • confirmed registrations
  • pending registrations
  • waitlisted registrations with an active offer

That means an event can still appear full even after one registrant cancels if there is already:

  • a pending checkout still holding seats
  • an unexpired waitlist offer reserving seats
Important

Active offers reserve capacity. A staff member may think "a seat opened," but the system may still treat the event as full because that seat is already being held for an offered registrant.

Step 4: Test the Waitlist Flow Before You Publish

Test the public flow using a real capacity limit and a realistic registration scenario.

Basic test

  1. Set the event capacity to a small number such as 1 or 2.
  2. Complete enough registrations to fill the event.
  3. Attempt one more registration.
  4. Confirm that the extra registration is treated as waitlisted instead of confirmed.

Free event test

For a free event:

  1. Fill the event.
  2. Join the waitlist using one more registration.
  3. Free a seat by cancelling or refunding a confirmed registration in a controlled test.
  4. Confirm that the next result matches the selected waitlist mode.

Paid event test

For a paid event:

  1. Fill the event.
  2. Attempt one more paid registration.
  3. Confirm that the result is waitlisted and offer-based.
  4. If an offer is created, test the signed offer link using the same email address used when joining the waitlist.
Tip

Test using the same number of guests or ticket quantities you expect in production. Capacity checks use seat units, not just the number of registration records.

Step 5: Manage Waitlisted Registrations in the Dashboard

There are two main admin-side places to work with waitlisted registrations.

Waitlist page on the event

From the event edit page, use the Waitlist action to open the dedicated waitlist page.

This page shows waitlisted registrations with:

  • name
  • email
  • waitlisted date/time
  • offer expiry
  • seat count

It also supports:

  • filtering to Active offer or No active offer
  • Send offer
  • Expire offer

Important behavior on this page:

  • Send offer checks capacity first
  • confirmed, pending, and active-offer holds are treated as reserved seats
  • Send offer refreshes the offer metadata
  • the page itself does not queue the offer email

Note: The success message on Manage Waitlist explicitly tells staff to use Resend offer email from the registrations table if they want the email queued there too.

Registrations relation on the event

From the event's registrations table, staff can also work with waitlisted registrations.

Confirmed waitlist-related actions include:

  • Send offer email
  • Resend waitlist email
  • Expire / revoke offer
  • Promote (free) for free registrations

The registrations view also supports:

  • filtering for Offered (active)
  • opening a registration slide-over to inspect waitlist timestamps
  • resending waitlist, offer, or confirmation emails from the slide-over

Promote (free) is only available for free registrations and only after seat availability is checked.

Step 6: Know What Staff Can and Cannot Do Around Attendance

Waitlisted registrations are not ready for check-in.

The confirmed manual check-in action in the registrations table only allows check-in for registrations that are already:

  • confirmed

That means:

  • waitlisted registrations cannot be manually checked in
  • pending registrations cannot be manually checked in
  • if someone is still on the waitlist, staff must resolve that status first

This is the right operational behavior for most nonprofits. A waitlisted person should not appear as attended unless they have actually been moved into a valid seat.

Troubleshooting

The event is full, but no one is being promoted

Check:

  • whether Enable waitlist is turned on
  • whether the mode is actually Automatic
  • whether the event still has capacity set above 0
  • whether a pending registration or active offer is still holding the seat

Automatic promotion only runs in automatic mode and only when seats actually become available.

Staff expected a paid waitlisted person to auto-confirm

That is not how the implementation works.

Paid waitlist handling is forced into offer-based behavior. Paid registrations do not skip straight from waitlisted to confirmed without going through the claim/payment path.

Staff clicked Send offer on the waitlist page, but no email went out

That can happen on the Manage Waitlist page.

The page refreshes the offer metadata, but its own success flow tells staff to use Resend offer email from the registrations table if they want the email queued there.

A supporter says their offer link does not work

Check:

  • whether the offer is still active
  • whether the offer has already been claimed
  • whether the supporter is using the same email address they used to join the waitlist

The public claim endpoint rejects mismatched email addresses and expired or already-claimed offers.

A seat should be open, but the event still shows as full

Check for:

  • pending registrations
  • active offers
  • overbook settings
  • registrations with guests or ticket quantities using more than one seat

Capacity is based on seat units, not just raw registration count.

Related Topics

Keep exploring

Related topics

Events Events Tutorial Events Events Reference Events How Event Waitlists Work Events Event Waitlist Reference