Manage a session waiting list in FileMaker: fill a cancelled seat fairly

1. Separate seats, records and queue order.

The file has four fictional participants and two sessions. S01, FileMaker foundations, has two seats. S02, Reporting workshop, has zero capacity and is closed. The participant and session pop-up menus display readable names while storing IDs.

A participant–session pair has one persistent registration record. For example, P03|S01 identifies Sam’s registration for S01. The separate registration UUID identifies that saved record through status changes. Two participants named Alex Morgan have different participant IDs, so their registrations remain separate.

• Registered occupies one seat.
• Waitlisted occupies no seat and has a saved queue sequence.
• Cancelled occupies no seat. The registration record remains.

The screen’s saved-record total includes all three statuses across both sessions. It is different from the selected session’s Registered and Waiting counts. Cancelling someone should reduce the relevant active count without deleting their record.

The queue sequence records joining order. It is not a display position that must be renumbered whenever someone leaves. The next person is the Waitlisted registration with the lowest sequence in the selected session.

2. Fill two seats and queue two people.

Load examples, choose S01, and register P01 and P02—the two Alex Morgan participants. Then select P03, Sam Rivera, and click Join waitlist. Do the same for P04, Taylor Chen.

Sam receives sequence 1 and Taylor receives sequence 2. The session still has only two Registered participants. Four saved records are correct: two have seats and two are waiting.

Repeating Join waitlist for someone already waiting leaves their registration ID and sequence unchanged. A repeated click must not create another record or move that person to the back. Try this in the example: note Taylor’s ID and sequence, click Join waitlist again, and compare both values.

The overview lists participants in its fixed display order. Read the saved sequence and the Next line to understand priority; row position and alphabetical names do not decide who gets the seat.

3. Cancel a place, then promote the next person.

Select P01 and click Cancel. One seat becomes available, but neither waiting participant moves automatically.

Cancellation saves one decision: P01 no longer occupies a seat. Promotion is a separate decision, made with Promote next. Keeping it explicit makes the change visible and easy to check.

Click Promote next. It uses the selected session’s queue, regardless of the participant currently selected. The action checks that a seat is available and promotes one person from the front. Here that person is Sam, P03.

The screenshot above selects Sam after promotion. To check record preservation yourself, note his registration ID before promotion and compare it afterward. Registered returns to two, Waiting falls to one, and Taylor becomes next. The total remains four saved registrations.

The participant menu does not automatically switch to the promoted person. The result message names the participant who moved. Selecting that person afterward lets you inspect their saved status and ID.

4. Protect priority when someone returns.

Next, cancel P02. There is now one available seat, while Taylor is still waiting. Select the already Cancelled P01 and try Restore.

Restore is refused because Taylor has priority. A vacant seat alone is not enough: Register and Restore must also check whether anyone is waiting. Otherwise either button could become a shortcut around the queue.

P01 can use Join waitlist to return at the back. The original registration UUID stays with the pair, but the new join receives a later sequence. Cancelling a waiting entry removes it from the active queue; rejoining is a new request for priority.

This later screenshot follows additional cancel-and-rejoin checks. P01 is waiting at sequence 4. Taylor has cancelled and rejoined at sequence 5, so P01 is now next. Taylor’s UUID still matches the earlier sequence-2 record, and the saved total is still four.

Gaps in sequence numbers are expected. The numbers preserve joining order rather than promising consecutive positions. A fresh run with fewer cancellations will produce different sequence numbers while following the same ordering rule.

S02 provides a separate closed-session check. Its zero capacity closes Register, Restore and Join waitlist; there is no queue to join.

5. Put the rules behind every action.

The example keeps the policy in a read-only helper, Check session queue, and routes Register, Join, Cancel, Restore and Promote through a shared worker, Apply waiting-list action. A button chooses an action; the worker checks the selected IDs and the saved state before changing anything.

The helper checks capacity, known statuses, active registrations and waiting sequences. Invalid data produces an error instead of being treated as an empty queue or a spare seat. A repeated action that already has its intended result returns without another write.

Queue selection filters by session and Waitlisted status, then sorts by the numeric sequence. The registration ID provides a stable tie-breaker:

WHERE "SessionID" = ? AND "Status" = ?
ORDER BY "QueueSequence", "RegistrationID"

This is the selection rule, not a complete paste-in script. The worker also checks query failures and record identity. Inspect the editable file for its full context and error handling.

A new join uses the highest saved sequence for that session plus one, including historical sequences retained on cancelled or promoted records. It does not use the current number of people waiting. Cancel and Promote preserve the historical sequence; only a new join assigns a later value.

Before writing, the worker checks seat and queue eligibility. It checks again inside its transaction and verifies that a promotion still targets the expected queue head. It then changes the existing record—or creates one only when that pair has no record—and checks the save result. Errors revert the attempted transaction and return an explanation.

A successful Commit Transaction saves the grouped changes. The interface reports success after that checked result, then refreshes the counts and selected registration.