Plan course enrollment around seats, prerequisites and withdrawals

Define the unit a participant joins

PostgreSQL documents mechanisms for coordinating competing updates to shared records through locking. For a course app, shared capacity belongs to a specific cohort or session. Distinguish the course description from its scheduled run. A participant enrolling in a November cohort should not consume capacity in every offering with the same course name.

Write the eligibility rule using the provider's actual policy. A prerequisite might be a prior course, an approved application or no prerequisite at all. Explain who verifies it and whether a submitted application holds a seat. Avoid letting an attractive enroll button promise immediate admission when review is required.

• PostgreSQL: explicit locking ↗

Choose when capacity is committed

Decide whether capacity is reserved on application, approval or completed payment. Each choice has consequences for pending applicants. If a temporary hold expires, define the deadline and the next state, and show staff how to identify holds that have not progressed.

Separate participant status from payment status. Someone may be approved but unpaid, paid but awaiting a required document, or withdrawn with an unresolved administrative action. Use enough states to represent real decisions without making one status field carry every aspect of the relationship.

Make withdrawals and transfers explicit

A withdrawal should release capacity according to the chosen policy and preserve the participant's history. If someone moves to another cohort, decide whether the destination seat is secured before the original one is released. Inform the participant of changed dates or location before the move is final.

Keep the instructor's roster focused on the information needed to teach and manage attendance. Administrative notes and payment details may belong in a different view. Specify those access rules before sharing the roster with staff or exporting it for use elsewhere.

Test the last seat and the returning participant

Use a sample cohort with one place left and attempt two enrollments. Verify that the final confirmed roster matches capacity and that the unsuccessful person receives an understandable outcome. Also test a participant who withdraws and later reapplies, so old history does not create a duplicate active place.

Run the instructor and administrator journeys separately. The instructor should find the correct roster, while the administrator can explain pending applications and available places. A useful enrollment app connects eligibility, capacity and participation clearly enough that staff can operate the next cohort without reconstructing decisions from chat messages.