When a place opens on a sold-out event, session, or function, the waitlist process decides who gets the offer, how you notify them, and how long they have to register. Set up those rules once, and every waitlist that uses the process follows them the same way.
What It Controls
A waitlist process is a named set of rules for an event, session, or function waitlist. Its most important setting is its mode.
An Automatic process offers each open place to the next person waiting, emails them, and moves to the next person if they do not register within the time you set. A Manual process leaves each step to staff, so no one gets an offer, receives a notice, or gets skipped until a staff member handles it from the waitlist panel. Because staff control the timing in a manual process, manual processes do not have a fixed registration window.
The process also stores the offer email, an optional final reminder sent after the offer, and settings for text-message notifications.
Where to Find It
Go to Meetings & Shows › Setup › Registration › Waitlist Processes to view, create, edit, or delete processes. You attach a process from the event, session, or function’s own capacity and waitlist settings. After you turn on Enable waitlist?, Waitlist Process: lets you choose from the active processes in your Rhythm account.
A waitlist process must already exist before you can attach it to an event, session, or function. To turn on a waitlist for a single session, edit that session, turn on Capacity Tracking & Waitlist Management, set its capacity, then turn on Enable waitlist? and choose the process. You turn on a function’s waitlist the same way, from the function’s own capacity settings.
The Settings
| Setting | Options | Default | Effect |
|---|---|---|---|
| Mode | Automatic, Manual | Automatic | Automatic offers places and moves on without staff action. Manual leaves every step to staff. Manual still requires the offer email below, even though a manual process never sends it automatically |
| How long should a contact have to register… | A number, with Business Days, Days, Hours, or Minutes | Hours | Used only in Automatic mode. This is how long the offered person has to register before Rhythm moves on to the next person waiting |
| Notification Email (offer email) | Sender, subject, body, with merge fields | Required | The email an offered person receives. It is required for both automatic and manual processes |
| Enable SMS/Text Message Notifications | On or off, then a message template | Off | Stores a text-message template alongside the email. No text message is currently sent from any waitlist process, so do not rely on this setting to reach anyone by text |
| Enable Final Notifications | On or off | Off | Adds a reminder sent after the first offer |
| How long after they are first notified… | A number, with the same time units | Hours | How long after the first offer notice the reminder goes out, even if the process has already moved the place to someone else |
| Final Notification Email | Sender, subject, body | Required when reminders are on | The wording for the reminder |
Dependencies and Precedence
Automatic and manual processes handle open places differently. In an automatic process, a cancellation or capacity increase frees a place, and Rhythm changes the next waiting person from Waiting to Eligible to Register. Rhythm emails that person and, if they do not register within the registration window, marks them Missed Registration Window and moves on to the next person without staff involvement.
In a manual process, those steps do not happen on their own. Staff must notice the opening, change the person’s status to Eligible to Register, notify them, and later mark them Missed Registration Window and move to the next person if they do not register, because no window runs automatically.
- Editing a process applies at once to every waitlist that uses it, including waitlists with an offer already running. If someone is partway through an offer, they get the new registration window or wording at their next step.
- Deactivating a process only stops staff from choosing it for a new event, session, or function. It does not change any waitlists that already use the process.
- Deleting a process is refused while an event still uses it. If only sessions still use the process, the delete succeeds, but those sessions keep pointing to a process that no longer exists, so their next waitlist offer fails.
- A waitlist advances only when a cancellation or a capacity increase frees a place. Using Modify Order to change a registrant’s session selections does not, by itself, remove a session or free a place, so it does not trigger waitlist movement.
- For a function waitlist, staff can move someone forward from the Function 360 record. Use the edit action next to that person’s row and change their status from Waiting to Eligible to Register.
Warning
In a manual process, changing a waiting contact’s status to Eligible to Register does not send the notification email by itself, even though the process requires and saves a notification email. That automatic send only happens in an automatic process. After you change someone’s status by hand in a manual process, notify them yourself.
Tip
If the waitlist is for a session or function instead of the whole event, use the Event group of merge fields in your templates to show that session’s or function’s details. For that offer, the Event fields use the session or function’s information instead of the event’s, and session.name is meant to return the session’s name.
There is one important exception when you preview the same template: the Event fields use the real event’s details instead, so the preview will not match what an actual session or function waitlist offer sends.
A waitlisted-contact-specific field, such as session_name or session_id, is not a reliable way to show the session in a waitlist email. Reports on these fields vary: some show no value, and some show the session’s underlying ID instead of its readable name. Use the Event group of merge fields described above instead of a waitlisted-contact session field.
Change Impact and How to Revert
A process change reaches every waitlist using it as soon as you save, including offers already in progress. Review your wording and timing carefully before saving, because there is no separate approval or staging step. To revert, edit the setting back and save again. Anyone whose offer already used the old wording or window before you reverted is not corrected retroactively.
Permissions
Creating a new process requires a dedicated create permission. Editing an existing process, and attaching a process to an event, session, or function, does not require a separate permission beyond being signed in to the Console.
Validation and Errors
- A name, a mode, and an offer email are required to save a process. An automatic process also needs a registration window, and a blank window blocks the save.
- The window must be at least 1, in whichever unit you choose.
- Sending a preview does not currently work. Selecting Preview on either email card opens a dialog where you choose a contact and event, or the identifier of a real waitlist entry, and where to send it. Selecting Send Preview always results in Unable to preview email, regardless of what you choose. There is no way today to see a live preview of a waitlist email from this form before it reaches someone on a waitlist.
- The preview dialog is not available until you choose both a contact and an event. Choosing a contact and event alone builds a hypothetical waitlisted contact to preview against, so a merge field tied to an actual waitlist record, such as a session or function detail, can come back blank or misleading. Choosing the identifier of a real waitlist entry instead previews the email against that person’s actual record, including its session or function, which shows those fields more reliably, though sending the preview does not work from either option.
Related Tasks
Turn on capacity tracking and a waitlist for an event, session, or function from that record’s own capacity and waitlist settings, then choose the process it uses. After a waitlist is active, staff work it from the Console. They move people off by hand when the process is manual, or watch an automatic process run on its own.
To test that a waitlist’s notifications work as expected, make sure capacity tracking and the waitlist are turned on with a process attached, that the process’s Notification Email is filled in, and that the event, session, or function has reached its capacity. A waitlist offer email can only be tested once there is a full place for someone to be offered.
You can report on waitlist configuration across your events from the Events > Events query, which has separate output fields for whether the wait list is enabled and which waitlist process is attached.