A professional course registration form should preserve what an adult learner requested without promising a seat the team has not confirmed. In Airtable, keep enrollment requests, course offerings, and confirmed enrollments separate. miniExtensions supplies the request form; a coordinator reviews capacity and moves an applicant through a deliberate offer-and-confirmation process.

This is useful when a small training team can review requests manually, especially when applicants have alternate dates. The key question is not how many forms arrived. It is which specific offering each person requested, what they would accept instead, and which seats staff actually confirmed.

Make a dated offering the unit of capacity

Imagine fictional Northbank Learning offering an adult presentation-skills workshop on December 3 and December 10. The course content is the same, but each date has twelve places. Avery prefers December 3 and would accept December 10. Quinn only wants December 3.

When December 3 fills, Avery’s alternate preference is useful information. Replacing the requested date with December 10 would erase the original request and imply agreement that has not happened. Preserve both choices, then ask Avery whether the alternative still works before confirming it.

The broader course registration guide covers forms, learning resources, and portals. This workflow concentrates on the period between requesting a place and joining the roster. Teaching, assignments, certificates, and payment collection remain separate.

Before sharing with end users, confirm a suitable paid plan or active trial. The regular free plan is for internal testing rather than deployment to end users. Check the current extension and child-form allowances for your workspace; child forms are counted across published extensions, not separately for each one.

Build a request-to-enrollment record structure

Use a base connected to miniExtensions and start with fictional learners. This example is for adult professional development and collects basic contact details rather than identity documents, health information, or records about children.

  • Courses: Course Title (single line text, primary field) and Public Description (long text). Create one “Presentation skills” record.
  • Offerings: Offering Label (single line text, primary field), Course (single link to Courses), Starts At (date with time), Timezone (single line text), Capacity (number, integer), Intake State (single select: Accepting requests, Waitlist only, Closed, Canceled), and Public Schedule (long text).
  • Applicants: Applicant Name (single line text), Email (email), and Internal Reference (single line text). Staff create or reconcile these records after reviewing incoming requests.
  • Enrollment Requests: Request Number (autonumber), Submitted Name (single line text), Submitted Email (email), Applicant (single link to Applicants, staff-managed), Preferred Offering (single link to Offerings), Alternate Offering (single link to Offerings, optional), Submitted At (created time), Request State (single select: New, Needs clarification, Waitlisted, Offer pending, Confirmed, Withdrawn), and Coordinator Note (long text).
  • Enrollments: Enrollment Label (single line text), Request (single link), Applicant (single link), Offering (single link), State (single select: Offer pending, Confirmed, Declined, Expired, Canceled), Offered At (date with time), Reply Due (date with time), Confirmed At (date with time), and Decision Note (long text).

Each request has one preferred offering and at most one alternate. An applicant can make requests for different courses, so their email is not a globally unique enrollment key. Each Enrollment records one offer or placement outcome. If an offer expires and a later offer is made, create another record rather than overwriting the first offer’s dates.

The coordinator checks for duplicate active requests using applicant identity, course, and intake period together. Do not interpret two similar names as the same person or delete a second request before resolving whether it is a correction, duplicate, or different course request.

Configure the form as a request intake

Create a miniExtensions Form targeting Enrollment Requests. Include Submitted Name, Submitted Email, Preferred Offering, and the optional Alternate Offering. Display enough schedule information in the offering labels to distinguish the course, date, timezone, and delivery format. Keep Applicant, Request State, and coordinator fields outside the applicant-facing inputs.

In each field’s settings, turn on Required for Submitted Name, Submitted Email, and Preferred Offering. Keep them visible because conditionally hidden fields do not enforce that rule. Test a blank submission before sharing.

For each offering selector, configure the linked field’s filters to show only Accepting requests or Waitlist only offerings. The linked-record selection documentation explains that this finder is filtered through its own settings, not restricted by selecting an Airtable view. Keep those filters separate from the staff’s Airtable queue views.

Set Allow users to link to Single Record under the linked field’s Advanced settings, following the single-record guide. Set this explicitly so the form’s one-record limit is clear; when no miniExtensions override is stored, the form falls back to Airtable’s preference. Disable creation and expansion of Offerings in both fields so applicants cannot create a class or edit its capacity while selecting a date.

Explain that selecting a waitlist-only offering requests a place in the queue. If the preferred and alternate choices are identical, staff can ask for clarification; this design does not claim an automatic cross-field validation rule. Use a confirmation message that says the request was received and a coordinator will review it, without promising confirmation or a response deadline.

Review requests against the current roster

The coordinator checks a staff view containing both blank Request State and New records. Blank values must not make a new submission disappear. They inspect the requested schedule, reconcile the Applicant link, and check whether any duplicate request or current enrollment already exists.

Capacity review uses the actual Enrollments for that offering. Count Confirmed seats and all Offer pending records until staff resolves them. Agree on that policy before offering the last place. In this example, an outstanding offer consumes one place until the coordinator marks it accepted, declined, or expired.

For December 3, suppose eleven seats are Confirmed and one offer is pending. The coordinator puts Avery and Quinn on the waitlist instead of treating the pending offer as spare capacity. Use Submitted At as the queue’s starting order, with a written policy for duplicates and any permitted exceptions. Timestamp order alone should not silently decide eligibility.

A filtered view or calculated count helps a person review the queue. It does not lock inventory against another coordinator working at the same time. Assign one coordinator to issue offers during each review period and require a final roster check immediately before recording a new offer.

Offer an alternative without changing the original request

The coordinator sees that December 10 has room and contacts Avery using the team’s normal communication process. They create an Enrollment linked to Avery’s request and December 10, mark it Offer pending, and record a clear reply deadline. Avery’s preferred December 3 choice stays unchanged on the request.

After Avery accepts, the coordinator checks capacity again, marks that Enrollment Confirmed, records Confirmed At, and changes the Request State to Confirmed. The request now leaves the active waitlist, avoiding an accidental second offer for December 3. Quinn remains Waitlisted because Quinn did not provide an alternate.

If Avery declines, mark that offer Declined. Agree whether the original request stays on the December 3 waitlist; do not infer withdrawal from declining a different date. Staff sends confirmation and next steps separately. Updating Airtable does not send an email in this design.

Handle a cancellation after the roster fills

When a confirmed learner cancels, retain their Enrollment and change its State to Canceled. The coordinator checks that the cancellation genuinely releases capacity, then reviews the active waitlist in its agreed order. Contact the next eligible applicant and create a new offer with its own deadline.

An expired deadline also needs action: the coordinator checks for a late reply, marks the offer Expired according to the stated policy, and only then reoffers the place. Reply Due is a stored time, not an automatic timer. If a course itself is canceled, staff must review every pending offer and confirmed enrollment and communicate the change.

Check the queue before accepting real requests

Try a full offering, a waitlist-only offering, a duplicate request, and an applicant who accepts an alternate date. Verify that closed offerings cannot be selected through either picker, applicants cannot create new offerings, and confirming an alternate removes the request from the active waitlist without erasing its preference.

This workflow uses manual capacity review and communication. Seat reservation guarantees, concurrent booking protection, payment reconciliation, automatic waitlist promotion, and reminder emails require separate systems or explicitly configured and tested processes. For a manageable professional course, the advantage is an understandable trail from request to offer to confirmed roster.