Public pages and enrolment requests

Start here when you run public sign-up links and carry responsibility for what lands in the queue. It explains how public visibility, staged enrolment forms, and request decisions work together in Classia. You will see where safeguards are strict on purpose, especially for under-18 enrolments and record matching. The aim is not more process; it is fewer preventable corrections once term is busy.

Start with the common issue

A familiar scene is posting a term reminder and waking up to 26 requests from three different class links. Two parents used old emails, one adult participant already exists in your records, and one beginner class is already at capacity.

If your public setup is loose, Monday becomes a queue-repair day. If your setup is tight, Monday is a decision day.

That is the difference this section is designed to make.

What must be true before the public journey works

Classia only serves public enrolment pages when core visibility rules are satisfied.

At account level:

• The account must allow public enrolment.
• Private accounts do not expose public enrolment pages.
• Demo accounts are treated differently and are not generally public.

At class level:

• The class must be published.
• Make this class publicly visible must be enabled.
• Archived classes are excluded from public enrolment.

If one of these is not true, families cannot continue the public flow. This is intentional. It prevents accidental live links from draft or stale records.

The public form is not one big form

Classia runs a staged five-step flow, with server-side checks between steps:

1. Who - self or parent/guardian.
2. Age - date of birth and age eligibility checks.
3. Details - participant details, plus parent details where needed.
4. Attendance - full term or single class, date selection if needed, payment plan selection.
5. Review - final confirmation before submission.

Each step has back navigation, but forward movement depends on passing validation. That keeps low-quality submissions out of the decision queue.

For single-class requests, the selected date is validated against both the term range and class day-of-week. For example, if a class runs on Thursday, a Tuesday date will be rejected even if it is in term.

Under-18 handling in public flows

The under-18 rule is clear and strict:

• If someone picks self and date of birth indicates under 18, online self-enrolment is blocked.
• The flow shows a parental consent message and does not continue.
• Child enrolments must come through the parent/guardian path.

This avoids ambiguous responsibility. It also avoids staff needing to "interpret intent" from incomplete requests later.

Public scenarios

Example: self-enrolment blocked for a 15-year-old

A 15-year-old tries to register for an evening beginner class by selecting self. After date of birth is submitted, the flow stops and asks for parent/guardian completion. The studio does not need to manually intervene to enforce this.

Example: age eligibility catches wrong class early

A class is configured for ages 4 to 6. A 9-year-old is entered on step 2. The request is blocked before contact details and payment plan selection, which saves admin time and parent frustration.

Request creation and match detection

When step 5 is submitted with confirmation, Classia creates an enrolment request entry in pending status. It also runs matching logic to spot existing records.

Possible outcomes include:

• matched existing profile when a clear existing profile match is found.
• possible duplicate when the signal is ambiguous.
• no match when there is no existing match.

Examples of duplicate signals include:

• same email but conflicting date of birth,
• multiple adults with the same parent email,
• a parent record linked to multiple families,
• parent email matches a family but participant details do not match a child record.

That detection is there to prevent duplicate household and participant records from accumulating quietly.

Known-email protection in the public journey

If an unauthenticated user submits a public request with an email that belongs to an existing user account, submission is blocked and sign-in is required for that email path.

Operationally, this avoids accidental account takeover patterns and keeps identity boundaries clearer for staff.

For studio support teams, this usually appears as: "I clicked submit and got asked to sign in." The fix is not to create another profile. The fix is to sign in and continue with the existing account.

Admin queue operations: what happens after submission

Pending requests are processed in the enrolment requests queue, which is scoped to admin users in the active account.

Admins can filter by:

• status (pending, waitlisted, approved, rejected, all),
• class.

For each request, the queue shows:

• enrolment type,
• chosen payment plan,
• capacity state,
• processing history,
• matching status.

Decision actions are explicit:

• Approve (with active or trial status choice),
• Waitlist (requires reason),
• Reject (requires reason),
• Resolve match or Confirm new when duplicate checks are flagged.

Capacity pressure and override behaviour

Approvals check class capacity using active/trial counts.

If the class is full, approval is blocked unless the admin enables capacity override in the approval dialog. That creates a deliberate pause under pressure and stops accidental overfill decisions.

In a 20-place class already at 20 active/trial enrolments, standard approval will fail. Override must be deliberately set.

Payment and portal follow-on actions after approval

When approval succeeds, Classia runs downstream actions:

• enrolment status change to active or trial,
• payment schedule build/recalculation for the approved enrolment,
• due-notification handling where applicable,
• portal access provisioning for payer-side access where profile conditions are met.

For UK studios, this is where communication clarity matters:

• If you collect by Direct Debit, explain collection timing windows.
• If card is offered, explain when it is used as an immediate path.
• Distinguish due now from overdue when speaking to families.

This prevents support churn caused by unclear payment language.

What this is not designed for

This flow is not designed for anonymous bulk imports, unmoderated auto-approval, or shared household credentials. It is built for controlled intake and accountable decisions.

Related guides

• Publish public class pages safely
• Public enrolment step by step
• Approve, reject, waitlist, and match resolution
• Enrolments and status management
• Payments and billing UK
• Trust, verification, and safeguarding

Related feature

• Online enrolment requests

FAQ

When can a class be enrolled from a public link?

Only when the account allows public enrolment and the class is published, publicly visible, and not archived.

What are the five public enrolment steps?

Who, Age, Details, Attendance, and Review. Classia validates each step before allowing the next one.

Why do some requests show possible duplicate?

Classia detected a likely existing record match and asks admins to resolve or confirm before approval.

Can admins approve requests when a class is full?

Yes, but only by explicitly enabling capacity override during approval.

What happens after approval?

The request is marked approved, enrolment status is set to active or trial, payment schedule creation runs, and portal access can be provisioned.

How does this protect children in public flows?

Self-enrolment for under-18s is blocked, guardian details are required for child enrolments, and account-level scoping remains strict.