Activity Messenger Help Center

Manage requests in the Waitlist module

The Waitlist module brings together requests from your registration forms. Use it to find a participant, distinguish their requests from their account owner’s information, review saved answers, identify possible duplicates and clean up old waitlists. You can still manage the queue and automations for each class.

Open the module and understand the three parts

In your organization, open Classes → Waitlist.

A waitlist request is not a confirmed class registration. The source form tells you where the request was made. It may be different from the common form that collects waitlist information.

Access and visible information

Your account permissions determine access. Form management is required to edit the form or remove and archive requests. Messaging requires the corresponding permission. Access to contact details, answers and class registrations also depends on your client information, class and attendance permissions.

If an action or information is missing, ask your administrator to check your permissions. Opening the module does not grant additional access to your account.

Find the right requests

The newest requests appear first. Use the selector above the table to choose Oldest first instead. This changes the display order; it does not reorder invitation priority.

You can combine these filters:

• Search requests: participant, account owner or email.
• Source form: one or several registration forms.
• Requested class: one or several classes. Two sessions may have the same name; Ended or Deleted helps distinguish old sessions.
• Show requests: Active, Expired, Deleted or missing courses, Archived or All requests.
• Request status: invitation or archival follow-up.
• Current registration: a recognized registration in the requested class, another class, no current registration found or identity requiring review.
• Possible duplicates only: potentially repeated active requests for the same identified participant, class and occurrence or attendance rule.
• Participants who requested multiple courses: different classes requested by the same recognized person, including through different forms. This filter does not by itself mean the person is registered in those classes.

Counts reflect the applied filters. Request and identified-participant totals can differ because one person can have several requests. Unidentified people are not counted as identified participants.

Use Reset to clear filters and Refresh to reload results. Pagination offers 10, 25 or 50 requests per page. Filters, sorting and answer-column choices are retained in the view’s address. Copy it to return to the same selection; anyone opening it still needs the appropriate permissions.

Read the table and open request details

Participant(s) / children identifies the person who wants to attend. Account owner identifies the contact, such as the parent. The same parent can appear on several requests without the children being duplicates.

The table shows the requested class, source form when available, request status, current registration and related participant requests. Depending on the request, it can also show a specific occurrence, a quantity of places or the requested course’s end date.

Click the participant or View details to review saved information, form responses, follow-up dates, recognized current registrations and other requests. All their requests in the table or View all requests in the details opens the participant’s history, including archived requests.

Form responses

Open Answer columns to display useful questions in the table. Saved answers remain available in request details when their columns are hidden. Changing the visible columns does not change customers’ answers.

Available columns come from the waitlist form. The module does not combine every answer from the source class registration form into each waitlist request.

Current registrations and identity review

Current registrations correspond to confirmed attendance assignments for classes with an ongoing or upcoming date. Pending registrations and fully completed classes are excluded.

Review identity does not mean “not registered.” Available information does not identify the participant with enough certainty. Review the request before removing it, especially when a parent has several children or an older request does not identify the participant.

Understand request statuses

Request status and Current registration answer different questions. Someone may have registered another way while their waitlist request still exists. A recognized historical registration may also retain its status after the class ends or is deleted.

Review duplicates and requests for multiple classes

1. Select Possible duplicates only or Participants who requested multiple courses.
2. Open the details and compare the participant, class, occurrence, responses and current registration.
3. Use View all requests to review history beyond the selected form or class.
4. Keep useful requests and remove only those that are no longer needed.

Detection flags cases for review. It does not automatically merge or delete requests. Requests for different occurrences are not necessarily duplicates. Siblings sharing an email must not be treated as one person.

Send a message to selected people

1. Apply the appropriate filters.
2. Select requests on the displayed page, individually or using the table-header checkbox.
3. Check the selected count and click Send a message.
4. Review recipients in the composer, write the message and choose its sending options.

This prepares a message; it does not send immediately. Selection applies only to the displayed page. If several requests belong to the same account owner, review recipients before sending. To contact a complete class queue, you can also use Message all in that class’s waitlist window.

Remove and archive a request

In the details, choose a Reason for removal, click Remove and archive this request, then confirm. For several requests, select rows on the current page, click Remove and archive, then confirm.

This closes the requests and their associated automations. It does not remove confirmed class enrollments or release places occupied by already registered participants. Use class registration management to cancel a confirmed enrollment.

Clean up ended or deleted courses without restarting invitations

Removing and archiving requests for an ended or deleted course does not trigger availability invitations by email or SMS to the other people waiting. Previously scheduled invitations for those courses are also blocked when they execute. The module’s removal action does not send the removed person a removal message either.

To clean up ended courses:

1. Choose Show requests → Expired.
2. Choose Request status → Expired — course ended.
3. Review the class, occurrence and end date in the request details.
4. Select requests on the page and click Remove and archive.
5. Repeat on other pages as needed. Choose Archived or All requests to find removed requests later.

For deleted courses, choose Deleted or missing courses, then verify Deleted course or Inactive request — deleted course before archiving. Course not found is a separate case to investigate; do not treat it as confirmed deletion.

An expired invitation for an active course is different

Expired includes both expired invitations and ended courses. A status of Invitation expired alone therefore does not guarantee cleanup without further invitations. If the course is still active, removing a request can recalculate its queue and reassign an offered place to the next person, according to its automation settings.

The selected removal reason does not change course dates or disable automation. When cleaning up past sessions, check the actual status rather than only selecting “Course ended” as the reason.

Manage a class queue

Click Manage waitlist queue on a row or in request details. The existing class waitlist window opens inside the module. The request targets its source form and occurrence when they remain available. The same tool is still accessible from the Waitlist column under Classes → All classes and events.

In this window, you can:

• Add a person, with an optional confirmation on addition.
• Restore a removed request when matching entries are available.
• Message all in the selected context.
• Reorder the queue. This changes priority; sorting the central table does not.
• Show only participants still waiting and review their statuses.
• Trigger automations when the class is active, automation is configured and space is available.

If you increase a class’s capacity, use the last button to start the availability check. If the original form or occurrence is unavailable, the module may prevent opening that queue. Request details and historical information remain useful for investigation. Queue management is not offered for deleted or missing courses.

Edit questions using Form settings

1. Click Form settings at the top right of the module.
2. The common waitlist form opens on its Form tab.
3. In the designer, use ⋮ → Edit on a block to adjust its label, fields or required answers. Use + to add a question offered by the designer.
4. Save changes in the editing windows.
5. Return to the module to review requests. Use Answer columns to display an additional question in the table.
6. Test from the class registration form: open its waitlist window and check which fields customers are asked to complete.

A newly created default form includes account-owner contact details, the participant, class and comment. Existing forms can be customized and may have different fields or ordering.

The Class field is hidden in the waitlist signup window and automatically filled for tracking. Customers do not need to enter the class. Requests remain automatically linked to the course; an older organization may have removed this question without losing that link. Some older descriptions may still say “Do not delete this question.”

Depending on organization settings, the public window may use the customized form or the standard window with account owner, email, mobile, participant and comment. Editing the common form does not automatically enable customized public capture for every class or organization. If a new field does not appear to customers, ask your administrator or support to check this setting.

The request-receipt confirmation and an invitation when space becomes available are separate communications. Class-block settings can select a particular confirmation template. For waitlist activation, per-class rules and invitation configuration, use the setup guide below.

Follow-up example

A parent submitted requests for two children. One is waiting for Monday tennis and the other for Wednesday tennis. Search the parent’s email, then check Participant(s) / children. These rows are not necessarily duplicates. If Monday tennis is an ended session, filter Expired — course ended and archive only its old requests. Keep the useful Wednesday request and manage confirmed enrollments separately.

Troubleshooting

Related guides

• Configure waitlists in class registration forms
• Manually add someone to a class waitlist
• Selling classes and events