Class Registration Form Template and Enrollment Workflow

A class registration form should collect only the information needed to place a learner in a course, explain the fee and cancellation terms, and confirm whether the learner is enrolled or waitlisted. To prevent overbooking, check and reserve the last seat on the server in one operation; a browser-side count cannot decide which of two simultaneous submissions gets the place.

Download the sample CSV · Download the form field specification

Class registration form template

Use this original field list for a small course, workshop, or training session. Mark optional fields clearly and collect only details the instructor needs.

Sample submission: Morgan Hale registers for “Intro to Woodworking,” session WOOD-2026-11-14, confirms the prerequisite, requests an accessible workbench, and sees “Enrolled” with registration ENR-2081. The accommodation request should be visible only to staff who need it to prepare the class. This is a synthetic example.

Registration, waitlist, and payment states

AI-generated editorial concept; not a screenshot of a deployed app.

Use records such as classes, learners, enrollments, capacity, payments, and notification_events. An enrollment should identify one learner and one class and move through defined states, for example started → pending_payment → enrolled, or started → waitlisted; cancellation moves an enrolled learner to cancelled and can trigger the next waitlist offer. Keep a unique idempotency key for a registration attempt so a double click or network retry cannot create duplicate enrollments.

For a free class, a server-side transaction should check capacity and create the enrollment together. For a paid class, reserve the seat for a short, explicit period while payment is pending. Confirm enrollment only after verified payment; release the hold after failure or expiry. If a delayed payment succeeds after its seat hold has expired, route it to a defined review or refund path instead of confirming a seat that may have been given to someone else. The exact hold duration and refund policy are business decisions to set before launch.

When the class is full, create a waitlist position rather than displaying a false confirmation. On cancellation or expired hold, the server should recheck capacity and offer the seat to the next eligible learner. The offer should have an expiry and a single-use acceptance action; acceptance must repeat the capacity check on the server. If two learners accept the same last place at once, only one enrollment can become confirmed.

Keep progress notices tied to the enrollment

Store every progress or notification event with an enrollment_id, learner_id, class_id, event type, unique event ID, and timestamp. Before creating a notice, verify that the enrollment belongs to that learner and class. This lets a teacher send a lesson-complete update for the learner’s actual class and keeps another learner’s status out of the message. A public discussion about e-learning notifications asks how to react to enrollment, lesson completion, quiz completion, and inactivity; it illustrates those four event types. Community question: student notifications in an e-learning app.

Use event types such as enrollment_confirmed, lesson_completed, quiz_completed, and inactivity_reminder_due. Give each event an idempotency key, and record when a notification was sent so retries do not send duplicates. An inactivity reminder is a scheduled decision based on the learner’s last activity; tie it to each active enrollment and suppress reminders for canceled or completed enrollments. Keep the notification preference and destination private to the learner’s account. This app design can store and process its own events; it does not imply a native connection to another learning platform.

Proposed app and acceptance checks

Build the proposed application with Atoms Cloud or Supabase, choosing one backend for the project. The Atoms Supabase guide explains that the connector must be followed by a built data feature and a save/readback check in the app and database. Atoms: Connect Supabase. Give instructors access to manage their classes and enrollments; let each authenticated learner view only their own enrollment and progress. Keep accommodation requests, contact details, and payment information private. Public class pages may show the course description, schedule, fee, and remaining availability without exposing learner records.

Acceptance checks should submit two simultaneous registrations for a class with one seat and confirm only one becomes enrolled or temporarily holds that seat; the other must receive waitlist status. Submit the same request twice and verify one enrollment. Fail or expire a payment and confirm the hold is released. Cancel an enrolled learner and verify that the server offers the seat to one waitlisted learner. Attempt to create a lesson event for a different learner’s enrollment and confirm the server rejects it. Refresh both instructor and learner views and confirm saved statuses and progress remain correct.

If tuition is collected through Stripe Checkout, confirm enrollment from a verified server-side payment event, not only from the browser’s success page. Stripe says webhook fulfillment is required because customers may never reach that page, and fulfillment logic must safely handle repeat or concurrent calls for the same Checkout Session. Stripe: Fulfil orders. Keep payment secrets on the server and test payment success, delayed success, failure, and duplicate event delivery before taking live tuition.

For related implementation patterns, see turning a spreadsheet into a web app and building a client portal.

Build prompt

Use this prompt to define the proposed registration workflow and acceptance checks:

Build a class registration app for a small training provider.
Use Supabase as the only backend for this project.
Create classes, learners, enrollments, capacity, payments, notification_events.
Add instructor and learner roles with authenticated ownership checks.
Instructors manage their own classes and enrolled learners.
Learners can read only their own enrollment and progress.
Keep contacts, accommodation requests, and payment details private.
Public class pages show course details and availability only.
Collect learner name, email, class/session, prerequisites, and consent.
Keep accommodation request optional and staff-only.
Store each enrollment with a unique idempotency key and status.
Check and reserve capacity in one server-side transaction.
For paid classes, reserve a seat for a defined short hold period.
Confirm paid enrollment only after verified server-side payment.
Release capacity after payment failure or hold expiry.
Route late payment success to review or refund, never overbook.
When full, create a waitlist position with an offer expiry.
Acceptance of a waitlist offer must recheck capacity on server.
Bind progress and notification events to enrollment, learner, and class IDs.
Add unique event IDs and suppress duplicate processing and messages.
Support enrollment, lesson, quiz, and inactivity event types.
Suppress inactivity notices for canceled or completed enrollments.
Seed a synthetic class with capacity one and two learners.
Test simultaneous last-seat requests; only one may be enrolled/held.
Test duplicate submit, payment failure, expiry, cancellation, and waitlist offer.
Reject a progress event tied to another learner's enrollment.
Refresh instructor and learner views and confirm persisted state.
Use test payments only until webhook fulfillment is verified.