Control who can register for a class

Use class, season, schedule, member-category, prerequisite, capacity, and purchase rules together to control registration. Test each intended audience in the Online Client; a class can be visible while a particular student, schedule, or purchase option is unavailable.

#Start with the result you want

Choose the simplest rule that expresses the real requirement.

Goal	Primary control to review	Also verify
Open registration to any eligible signed-in client	Class Online Client Registration, visible/open season, future schedule	Client sign-in, pricing, cart, and checkout
Hide a class while it is being built	Season Visible for Client off or another approved visibility control	Do not rely only on a Closed registration action
Open registration on a future date	Season Enrollment Start	Time zone and member-category early dates
Give a member category earlier access	Season member-category enrollment date	Active category dates on the exact student
Limit registration to selected member categories	Class allowed Online Client member categories	Category activation and expiration
Enforce an age range	Class minimum/maximum age plus global age checking	Accurate birth date and the age-offset setting
Require earlier class experience	Prerequisites enabled and complete prerequisite groups	Recorded member prerequisite visits
Stop when capacity is reached	Class or schedule capacity and full-class checking	Current active enrollment count
Offer a waiting list when full	Studio, season, and class waitlist controls	Waiting-list purchase and notification behavior
Limit who can buy the price or package	Sales Item purchase restrictions	The class can be eligible while every price is restricted
Use an invitation process	Class invitation/eligible workflow	Delivery and checkout behavior require separate testing

Avoid collecting or restricting by personal information merely because a field exists. Use age, category, or other eligibility data only when the studio has a legitimate operational need and an approved policy.

#Think in five gates

Registration is a sequence, not one permission check.

1. Can the viewer find the class and schedule?
2. Can this account select an eligible student?
3. Is the schedule open and below capacity, or is waitlist allowed?
4. Is there an eligible price, package, plan, or existing credit?
5. Does final cart/checkout validation still pass?

Test all five. Passing an earlier gate does not guarantee the final submission.

#Before you change rules

Record the class, season, schedules, current visibility, registration setting, capacity, and pricing model.
Identify the people who should be eligible and at least one realistic exclusion case.
Confirm whether the rule belongs to the whole class, one schedule, a season, a student category, or one Sales Item.
Review existing enrollments, waiting-list rows, purchases, charges, and future payments before closing or changing an established offering.
Use fictional test accounts with deliberate ages, category dates, prerequisites, and purchase histories.
Disable or intercept outbound notifications during rule testing.

Warning: A status or eligibility change can affect registration, waiting lists, purchases, tuition, messages, reports, and content access. Change one source at a time and record the before value.

#1. Control discovery and registration timing

Review the season first:

Confirm Visible for Client.
Confirm the season status.
Confirm Enrollment Start and the studio time zone.
Review Block Registrations.
Review member-category enrollment dates.
Confirm the schedule belongs to that season and falls inside the intended range.

Current class actions also consider cancelled/inactive season or schedule state, general or new-account registration blocking, and how far in advance a schedule may be booked.

Visibility and registration are separate. A studio can intentionally show a future or closed class without offering an action, but that is not a privacy boundary. Use an actual visibility rule when the class must not be discoverable.

#Early registration by member category

A student's active member categories can provide an earlier season enrollment date.

Create or identify the member category.
Set its season-specific enrollment date on or before the general season start.
Confirm the category is active for the test student on the test date.
Test before the category date, between the category and general dates, and after the general date.

If several active categories have dates, a matching date that has opened can allow eligibility. Do not infer the result from the family account alone; the category check is performed for the selectable student.

#2. Limit eligible students

#Age range

Class minimum and maximum ages are enforced by the current Online Client eligibility service only when studio-wide age checking is enabled and the class does not ignore age.

The service calculates an effective age from the student's birthday and the configured age-offset days. It then compares that age with the class range.

Important: In the current implementation, a missing or unreadable birthday does not create an age mismatch. If birth date is required for safe age enforcement, make it a complete-data prerequisite and test a missing-birthday account. Do not describe the age rule as airtight until that case is resolved.

#Allowed member categories

Choose the allowed Online Client member categories on the class.
Confirm each test student's active category relationships.
Review category activation, expiration, and status.
Test an allowed student, a student with only a different category, and a student with no category.

If the class has no allowed-category list, the current eligibility service does not block by member category. If it has a list, at least one active student category must match.

Membership purchase, membership-category assignment, renewal payment, and category dates are separate state layers. Verify the category relationship itself when it is being used as the gate.

#Prerequisites

Prerequisite checks apply only when the studio setting is enabled and the current prerequisite tables and fields exist.

The current service treats each prerequisite group as required. Within a group, it sums recorded visits across the listed prerequisite classes and compares the total with the group's required visits. All groups must be complete.

Define the intended prerequisite class groups and required visits.
Confirm the student's recorded prerequisite visits.
Test a student below the count, exactly at the count, and above it.
Review the message at student selection or purchase-option selection.

Note: When prerequisites are the only blocker, the class list can still show Book Now so the per-student flow can explain the missing prerequisite. Do not treat that list action as proof that every student is eligible.

#3. Configure capacity and waiting lists

Capacity can come from the schedule or class. Review the value that applies to the exact dated occurrence and compare it with current enrollment.

When the class is full, the Online Client can show:

Wait List when the studio, season, and class all permit it and advance-booking rules pass;
Full when no waiting-list action is available; or
an existing Waitlisted state for a student already waiting.

Test a nearly full schedule, the final available spot, and a full schedule. Decide whether a waiting-list registration should create or reserve a purchase in the studio's chosen pricing path; current admin enrollment source can create a Sales Item purchase for a Waiting status, so this consequence needs explicit end-to-end verification.

Do not raise capacity simply to bypass a test failure. Confirm room, instructor, safety, and policy limits first.

#4. Control the purchase option

A student can pass class eligibility but still have no valid way to purchase it.

Review the class's pricing model:

Billing Schedule rows and prices;
assigned Sales Items or packages;
payment plans;
existing eligible purchases or credits; and
zero-dollar registration policy.

For a Sales Item, review its own:

active and visible state;
sale start and end dates;
class, schedule, season, location, instructor, category, client, or student restrictions;
age or membership restrictions where configured;
quantity and customer purchase limits;
activation and expiration;
included uses and maximum courses;
payment plan and contract; and
whether an existing purchase is already assigned or exhausted.

The server rechecks eligibility and purchase restrictions when the option is submitted. A price that appeared earlier can be rejected after the underlying data, date, inventory, capacity, or account state changes.

#5. Test the complete matrix

Use a clean signed-in session for each fictional account.

Test person/state	Expected result
Eligible student with an eligible price	Class and schedule visible; action available; intended purchase option accepted
Wrong member category	Clear restricted/ineligible result
Below or above age range	Age-ineligible result when age checking and complete birthday data apply
Missing prerequisite visits	Prerequisite-required result in the student or option flow
Before registration opens	Not-open-yet result with the expected date
Full schedule with waitlist enabled	Waiting-list action and the intended purchase behavior
Full schedule without waitlist	Full state without a registration action
Eligible class but restricted Sales Item	No eligible option or a clear item restriction
Already enrolled, attended, or waitlisted	Disabled existing-state action rather than a duplicate registration

For each result, test the class list, calendar, class detail, student selector, purchase options, cart, and final server response as applicable.

#Verify one approved registration

After the matrix works, complete one controlled registration using an approved no-payment or test-processor path.

Confirm:

the order result and order number;
the intended student, class, season, and schedules;
enrolled versus waitlisted state;
the admin roster and capacity count;
the purchase or Billing Schedule relationship;
charges, payments, credit, fees, and balance;
scheduled or recurring payment instructions;
agreements and question responses; and
notifications and history.

Do not open registration broadly until the allowed and denied cases both behave as intended.

#Diagnose where registration stops

Symptom	First checks
Class absent from every client view	Season visibility/status, schedule dates/status, class active state, Online Client display settings
Class visible but no action	Registration mode, season block, enrollment date, advance-booking rule, capacity, existing state
No family member can be selected	Account/family mode, active student status, age, member category, prerequisite, enrollment window
One student is disabled	Read the student-specific reason; compare that student's data, not the family account generally
Purchase options empty	Billing Schedule price, assigned Sales Item, sale window, restrictions, existing credit eligibility
Option appears but submission fails	Underlying data changed or the server-side recheck found a restriction; refresh and inspect the specific result
Checkout succeeds but class is missing	Order status, waitlist or registration-fee-only result, roster, schedules, purchase, and ledger

#Troubleshooting

#A student should be eligible but is restricted

Review the student's active category dates, birthday and effective age, prerequisite visits, season enrollment date, exact schedule, and the assigned price. Compare the student ID used by the client session with the record you inspected.

#An age-restricted student can still continue

Confirm global age checking is on, the class does not ignore age, the range is saved, and the student has a valid birthday. The current service does not block an unknown age.

#The member category is correct, but registration has not opened

Confirm that the season contains a category-specific enrollment date for that category and that the student's category is active. If the matching category date is absent, the general season date applies.

#Prerequisite behavior is inconsistent

Confirm prerequisites are enabled and both prerequisite and member-visit records are available. Review every prerequisite group; completing one group does not satisfy the others.

#The class shows Book Now for an ineligible student

Open the student-selection or purchase-options flow. The current list can defer a prerequisite-only explanation to that next step. If another restriction is being deferred incorrectly, capture the class, student, schedule, and reason for product review.

#The waitlist creates an unexpected purchase or charge

Stop further tests. Record the class, schedule, student, option, order, purchase, charge, and payment. Waiting-list finance consequences vary by route and must be reconciled before launch.