Outcome and scope
Collect workshop applications and separate provisional seat candidates from a waitlist. An immediate receipt acknowledgment is different from a confirmed seat. This design does not promise that counting spreadsheet rows creates a reliable concurrent booking lock. Assign a person or a transactional booking system to make the final capacity decision.
Capacity belongs to people, not response rows. Define how groups, reserved operational places and a later capacity change affect the available count.
Prepare the fields and destination
Prepare these fields: Application ID, session ID, received time, party size, review state, waitlist order and confirmation notification time. Keep source values separate from a reviewer’s confirmed values, and do not reuse an existing column for a different meaning. Create the first record with practice identifiers in a destination whose read and edit access matches the intended staff roles. Inspect the saved result from that role before using live information.
The waitlist needs a policy for groups, offer deadlines and unreachable applicants. Avoid repeatedly broadcasting changing positions when those numbers do not guarantee a seat.
Build the workflow in order
Maintain capacity and closing time for each session separately from applications. On intake, deduplicate by application ID and hold missing, zero or excessive party sizes for review. The same email address can legitimately apply for another session, so it is not a suitable unique key for all applications.
Retrieve confirmed attendance for that session and compare remaining capacity with the requested party size. Record the route as provisional and explain the confirmation stage in the receipt message. Decide in advance whether a group may be split; the scenario should not invent a policy when only part of a party fits.
When a cancellation creates capacity, review the waiting list in the agreed order and offer a place with a response deadline. Move the applicant to confirmed only after acceptance. An outstanding offer is a separate state from a confirmed attendee, so staff can see capacity that is temporarily held.
Work through a small example
Consider a session with capacity eight and six confirmed attendees. A party of three should not be automatically confirmed against two remaining seats. Under a no-split rule, it becomes a waitlist candidate. If a cancellation later creates three spaces, check for an outstanding offer before contacting that party.
| State | Check | Action |
|---|---|---|
| Not enough space | Two places; party of three | Keep as a waiting candidate |
| Concurrent requests | Both read the same capacity | Reconcile before confirmation |
| Outstanding offer | Before deadline; not accepted | Track as held, not confirmed |
| Confirmed place | Accepted and capacity checked | Record confirmation and time |
Handle changes during operation
If payment is added, keep paid, offered and confirmed states separate. Test concurrent applications, late submissions and expired offers before allowing any automatic confirmation route.
Estimate cost and usage
Model intake, capacity lookups, notifications, waitlist offers and cancellations separately. More sessions introduce additional review and exceptions, so one sample application is not a reliable monthly budget. Include staff confirmation time. If immediate guaranteed reservations are essential, compare the cost and capability of a dedicated booking system rather than pricing only the form scenario.
Investigate failures
Two concurrent applications may read the same remaining capacity. Do not assume a visual scenario order eliminates that race across separate executions. Require reconciliation before final confirmation. If overbooking occurs, stop confirmation notices and review the seat and offer histories rather than deleting the latest applicant without explanation.
Review before release
Before release, test a normal record, one missing a required value, a repeated identifier and an edited record. Use application id to trace the saved result back to the source. The acceptance condition is: Separate received, waiting, offered and confirmed states before sending seat confirmations. Record the expected result before testing, compare it with the actual saved state, and resolve unexplained differences before increasing the scope.
Start a small workflow in Make
Try the required workflow with practice data, then choose a plan around its usage and features. Check current prices, promotions and eligibility in the official signup flow.
Sign up on MakeAffiliate linkEstimate costs for your workload
Enter monthly jobs, billable steps and retries to see how different billing units affect your estimate.
Open cost calculatorOfficial sources
Pricing, availability and feature limits can change. Check the linked official pages before subscribing.
- Make: Working with filesInformation checked: 2026-10-30
- Google Sheets modulesInformation checked: 2026-10-30
- Make: Incomplete executionsInformation checked: 2026-10-30
- Make pricingInformation checked: 2026-10-30
- Make pricing — Core at 10,000 monthly creditsInformation checked: 2026-10-28
- Make creditsInformation checked: 2026-10-26
- Make scenario settingsInformation checked: 2026-10-26
