Event waitlists and capacity

What it does

When an event or session hits its capacity, further registrations are held with a status of Waitlisted instead of being rejected. As places free up, the platform promotes the oldest waitlist record — either straight to Registered, or to an invited state where the contact has to confirm.

Key facts

Event-level settings live on the event's General tab in the Capacity area: Maximum event capacity, Waitlist this event (Yes/No) and Auto-register waitlisted contacts (Yes/No).
Session-level settings are the same three fields, on the session's Summary tab under Capacity: Maximum session capacity, Waitlist this session, Auto-register waitlisted contacts.
Promotion order is oldest first, by the registration date and time on the waitlist record. There is no priority, no manual reordering, no VIP jump.
With Auto-register waitlisted contacts set to Yes, the platform creates the event registration record itself the moment a place opens. The contact finds out only if you send them something.
With it set to No, the contact has to confirm. The documented pattern is an Invite flag on the event registration record, a segment of people where auto-register is No and invited is Yes, and a journey email asking them to confirm.
Status reason on the registration record is the thing to watch: Waitlisted, Registered, Canceled. Everything is visible on the event's Registration and attendance tab.
Two triggers are available to real-time journeys: Marketing event registration created, which fires when a new waitlist registration is created, and Marketing registration created from waitlist, which fires when a record moves from Waitlisted to Registered. The second is the one you build the "you're in" email on.
Event and session waitlists interact in three documented ways. Event has room but the sessions are full: the attendee registers for the event and sees a "join waitlist" notification on the full sessions. Event is full but sessions have room: the session registrations are put On hold until an event place opens. Both full: the attendee is waitlisted for both and gets registered for both together when an event place opens.
No documented cap on waitlist size. Capacity limits the registrations, not the queue.

When to use / skip

Use it for anything oversubscribed where the client would otherwise be running a spreadsheet — training courses, room-limited breakouts, popular customer events. The promotion logic and the two journey triggers give you a working "a place has opened" flow with very little build.

Skip it for virtual events with a thousand-seat Teams webinar and two hundred registrants. Enabling a waitlist that never fills is harmless but it invites the client to configure a confirmation journey they'll never use, and it adds a status the reporting team has to explain.

The auto-register decision is the real choice. Auto-register is right when a place is valuable and the client wants it filled — training, paid seats. Confirmation is right when a no-show is expensive and someone waitlisted three weeks ago may well have forgotten. Most clients say "auto" in workshop and mean "confirm" once you describe the no-show problem.

Configuration decisions

Waitlist at event level, session level, or both — and if both, that you've thought through the on-hold behaviour when the event fills before the sessions do.
Auto-register versus invite-and-confirm, per event. It is a per-event field, so it can vary, but a client with fifty events a year wants a default and a rule.
If invite-and-confirm: how long a contact gets to respond, and what happens when they don't. Nothing in the platform expires an invitation for you.
Which of the two journey triggers you build on, and whether the waitlisted contact gets an acknowledgement at the point of joining the queue as well as at promotion.
Whether cancellations feed the waitlist promptly enough — the queue only moves when a place actually frees up in the data, not when someone tells the organiser by email.
Whether capacity is enforced at the venue layout, the event, or the session, since the waitlist keys off whichever number is actually on the record.

Gotchas

Auto-register with no confirmation journey behind it is the classic failure: people get registered silently, never hear about it, and don't turn up. The registration is created; the email is entirely your job.
Invite-and-confirm has no built-in expiry. Without a journey that times out and moves to the next person, a single unresponsive contact holds a place indefinitely.
On-hold session registrations confuse everyone. Someone looks at a session, sees registrations that aren't counted against capacity, and reports it as a bug.
Promotion is strictly first-in-first-out. If the client expects to prioritise partners or key accounts, that is custom work, not configuration.
The waitlist works off the capacity number on the record. If someone has hand-edited event capacity away from the room layout value, the waitlist enforces the hand-edited number and nobody will connect the two.
Manually created registrations — phone bookings entered by an events team — consume capacity like any other, and will push web registrants onto the waitlist without warning if the team is entering a batch.
The invite-and-confirm path as documented leans on a segment plus an email, which is fine, but it means the flow depends on segment refresh timing rather than firing the instant a place opens.

Consultant notes

Walk the client through the no-show maths before they pick auto-register. It reframes the decision in about a minute.
Build and demo the promotion email off Marketing registration created from waitlist in UAT with a capacity of two. It's the cheapest convincing demo in this module.
Tell the events team explicitly that manual registrations count against capacity. They will otherwise batch-enter phone bookings the morning registration opens and wonder why the website started waitlisting.
If invite-and-confirm is chosen, get the expiry rule written into the design and build the timeout branch. It is the most commonly missed piece.
Check before go-live that capacity on the production event matches what the client thinks it is, especially where a venue layout was selected and then overridden.

Worth another look if Microsoft adds priority or manual ordering to the waitlist queue — first-in-first-out is the main thing clients ask to change.