Open this guide for the part nobody can delegate forever: making clean decisions on pending enrolment requests. It explains how to process queue items without creating duplicate records, unsafe links, or payment confusion. The emphasis is consistency under load, not speed at any cost. If your queue decisions are stable, the rest of the term is easier.
A practical queue rule before anything else
Do not process requests in random order while answering messages in parallel. Pick one class filter, clear it, then move to the next.
That single discipline reduces contradictory decisions, especially when a class is near capacity or has many sibling requests.
For studios handling 20 to 40 public requests per week, this often cuts rework by half.
What the queue actually shows
The enrolment requests page gives admins filtered decision context:
- participant and relationship details,
- class and requested attendance type,
- payment plan name,
- capacity state,
- submission time,
- decision history,
- matching status.
Use status filters (pending, waitlisted, approved, rejected, all) and class filter together. Broad all-class processing feels efficient but usually creates context loss.
Decision options and their rules
Approve
Approval requires choosing enrolment status:
active, ortrial.
If class is full by active/trial count, approval is blocked unless capacity override is explicitly enabled.
Approval on success updates request state and runs enrolment/payment actions downstream.
Waitlist
Waitlisting requires a decision reason. It keeps the request in a managed deferred state and records why.
Reject
Rejection also requires a decision reason. Keep it factual and short. Families may see this reasoning context.
Capacity override should be deliberate, not normal
Capacity override exists for edge cases, not as default behaviour.
Use override when there is a specific operational reason, for example:
- a planned split group that starts next week,
- temporary dual attendance during class transition,
- manual staffing cover already confirmed.
Do not use override as a routine fix for oversubscription. That usually creates register and staffing strain.
Example: class full but sibling coordination needed
A class is at 16/16 active-trial capacity. One sibling has an existing place and another sibling request arrives. Studio chooses waitlist first, confirms staffing for an extra spot next month, then approves with explicit override at that point.
Possible duplicate handling
Some requests are flagged possible duplicate. Approval is blocked until this is handled.
Admins then choose one of two paths:
Resolve matchto link to existing participant/family/adult records.Confirm newif it is genuinely a new person and should proceed as such.
This is where data quality and safeguarding meet. Rushing this step creates long-term record noise.
What resolve match validates
Match resolution checks that selected records are valid in the same account and that enrolment conflicts are avoided.
For under-18 participants, additional checks apply:
- family is required,
- responsible adult is required,
- responsible adult must belong to the selected family.
If the request already has an enrolment, updates are propagated so enrolment links stay aligned.
Example: parent email matches existing adult with wrong family
A parent email matches an adult record, but selected family does not contain that adult. Resolve-match rejects the update until family/adult pairing is valid. This prevents unsafe guardian links.
Example: existing participant already enrolled in same class
Admin selects a participant in resolve-match, but that participant already has a conflicting enrolment for that class period. Match resolution blocks with an enrolment conflict error. This avoids duplicate class enrolments for one participant.
What happens after successful approval
When approval completes successfully, Classia proceeds with follow-on actions:
- request status becomes approved,
- decision status is recorded,
- enrolment transitions to active or trial,
- payment schedule build/recalculation runs,
- payer notification can be sent for due items,
- portal access provisioning can be triggered for parent/participant paths.
This is why approval quality matters. You are not only changing a label. You are triggering downstream state.
UK communication patterns that reduce friction
Decision messages work better when they are specific.
Examples:
- Good waitlist message: "Class is currently full at 18 places; we will review after first two weeks of attendance."
- Good reject message: "Selected age is outside this class range; we can offer Tuesday 6-8 group instead."
- Good approval follow-up: "Request approved as trial; payment schedule will appear in portal."
Avoid generic messages like "not suitable" when a clear reason exists.
Pitfalls to avoid
- Approving requests while possible-duplicate status is unresolved.
- Using capacity override by habit instead of documented exceptions.
- Rejecting or waitlisting without a specific reason.
- Clearing queue by timestamp only, ignoring class-level context.
- Changing household links to force approval instead of fixing match selection properly.
Related feature
Pitfalls to avoid
- Approving requests while possible-duplicate status is unresolved.
- Using capacity override by habit instead of documented exceptions.
- Rejecting or waitlisting without a specific reason.
- Clearing queue by timestamp only, ignoring class-level context.
- Changing household links to force approval instead of fixing match selection properly.
Related guides
FAQ
Who can process enrolment requests?
Enrolment request queue actions are admin-scoped in the active account.
Can a possible-duplicate request be approved immediately?
No. Possible-duplicate requests must be resolved or confirmed as new before approval can proceed.
When is waitlist reason required?
Waitlist and reject decisions both require a reason.
What does capacity override do?
It allows approval to proceed even when active/trial enrolments are already at class capacity.
What happens to request status after approval?
Status moves to approved, decision status is set, and enrolment/payment follow-on actions run.
How does match resolution protect under-18 records?
Under-18 match resolution requires family and responsible adult consistency before updates are accepted.