Event Capacity, Waitlist, and Session Overflow
Northwind runs a two-day in-person conference with a main hall seating 500 and three breakout rooms seating 80 each. Registration is through a Dynamics 365 Customer Insights – Journeys event. The event is configured with a capacity of 500 and a waitlist enabled. Breakout sessions are separate sessions within the event, each with its own capacity of 80. Registration opened to all contacts. Within a week, 620 people registered for the event and 300 selected the same popular breakout, 'AI in Practice'. The waitlist has 120 people on it. Northwind's ops lead wants to know why 620 confirmations went out when capacity is 500, and why the breakout session shows 300 registrants against a capacity of 80.
1. Explain the discrepancy between event capacity and confirmed registrations, and how waitlist behavior should have been configured.
Read the worked answer
Event-level capacity and waitlist are not an automatic gate on registration unless the registration flow is built to honor them. In this setup, registration was open to all contacts and the confirmation email fired on registration, so the platform registered everyone who submitted the form - 620 - and the 120 waitlist entries were people who chose the waitlist path or were added by ops, not people the system diverted.
The judgement call: capacity is a number you enforce, not a switch that enforces itself. To make 500 a hard ceiling you need:
- A registration flow that checks current confirmed count before confirming, and routes to waitlist when count ≥ capacity.
- Waitlist as an explicit status on the registration record, with the confirmation email suppressed for that status and a separate waitlist email sent instead.
- A promotion process: when a confirmed registration is cancelled, ops (or an automated step) promotes the oldest waitlisted registrant and sends the confirmation then.
Also decide what 'capacity' means - 500 per day or 500 total. A two-day event with 500 seats likely means 500 unique attendees, which is what was configured, but the ops lead should confirm before any promotion logic is written.
2. The 'AI in Practice' breakout has 300 registrants against 80 seats. Describe how to resolve this without cancelling the event registration, and what to change for the next event.
Read the worked answer
Separate the two registrations. Event registration (620 confirmed, 120 waitlisted) and session registration (300 for one breakout) are different records and different capacities; the 300 must be resolved at the session level, not by touching event registration.
Resolution for this event:
- Move 220 session registrants to a waitlist status for that session and notify them with a clear message: confirmed for the event, waitlisted for the breakout, with the alternative sessions listed.
- Offer the two other breakout rooms as overflow - 160 seats total - and let waitlisted registrants self-select into them via a session-change form.
- If demand persists, run the popular breakout twice and split the audience by the original registration timestamp, which is auditable and feels fair.
For the next event:
- Set session capacity and enable session-level waitlist independently of event capacity.
- Make session selection a required step in the registration form with live remaining-seat display, so the 300 never accumulates.
- Add a session-change journey that respects capacity on every change, not just on first registration.
The trap is treating session capacity as inherited from event capacity. It is not; each session needs its own gate.