What happens when a child is enrolled
Enrolling a child into a program looks like a small thing on screen: pick a child, press Enroll. It is also the only place in PTRS where a state licensing figure changes what actually happens next.
This page traces what happens, in the order it happens, and then covers the two other paths that reach the same roll and behave differently.
The six checks, in order
Enrolling a single child from a program's overview runs six checks and stops at the first one that fails.
1. The child exists
PTRS looks the child up within your own organisation. A child belonging to another organisation is treated the same as one that does not exist at all, and the enrolment is refused as not found.
2. The program exists
Same check, against the program. Note what is not checked here: the program's own lifecycle stage. A program in Draft, Suspended, Completed or even Archived accepts an enrolment exactly as an Active one does. The program's date range is not checked either: a program that ended last August can still be enrolled into today.
3. The site's licensed capacity
This is the check that matters, and it is the only one of the six that reaches outside this module at all.
PTRS asks Centers whether the site is at its licensed capacity. Centers reads the site's own licensed capacity figure, falling back to the site's general capacity when no licensed figure is on file, and counts every distinct child with an active enrolment in any program at that site. If the count has already reached the maximum, the enrolment is refused with a message naming the site, its current headcount and its maximum, and PTRS writes a note to its own log as well.
Three things make this check meaningfully different from the rest of PTRS:
- It counts across every program at the site, not just this one. A child in three programs at the same site counts once, which is the right unit: a licence limits children on the premises, not enrolments.
- It counts only active enrolments. Waitlisted, withdrawn and completed enrolments do not use up licensed capacity, which is also right.
- It is the only place anywhere in PTRS that this particular check is ever run.
The Compliance and Centers module pages once recorded this check as living in Members, and said it was the one place in either module where a licence figure has a real consequence. Creating a child's record performs no capacity check of any kind; the actual check lives here, in Programs. The finding itself still stands, verified here from this side of the product.
4. The program has an active schedule
An enrolment attaches to a specific schedule, not to the program directly. Failure here means the program somehow has no active schedule.
In practice this always succeeds, because creating a program also creates one schedule, and nothing in the product can deactivate or add another one. It still matters for two reasons.
If a program somehow ended up with two active schedules, the child would be attached to whichever one PTRS happened to read first, with no way for whoever is enrolling to choose between them. And capacity is compared against the wrong figure in that case too: the next check counts enrolments on this one schedule and compares them with the program's capacity, not the schedule's own. With one schedule per program those numbers are the same; with two, a program with a capacity of 30 would allow 30 children per schedule instead of 30 in total.
5. Not already enrolled
An active enrolment for this child on this schedule is refused as a duplicate.
The check here only looks at active enrolments, while PTRS also refuses two enrolments for the same child and schedule at a deeper level, regardless of status. So a child who was withdrawn, or who is waitlisted, passes this check and then fails at that deeper level instead, as a plain server error rather than the clear duplicate message.
The Enroll picker is protected from this by accident: it filters its search results against the program's full enrolment list, which includes withdrawn and waitlisted rows, so such a child never appears as an option in the first place. The exposure is only to someone integrating directly against PTRS rather than through the screen.
6. Program capacity, and the waitlist
Active enrolments on the schedule are counted and compared with the program's own capacity.
| Situation | Result |
|---|---|
| Below capacity | The child is enrolled as active |
| At or above capacity, waitlist enabled | The child is placed on the waitlist, with a position worked out from how many are already waiting |
| At or above capacity, waitlist disabled | The enrolment is refused |
The waitlist setting is off on every program created through the standard Quick Add dialog, because that form has no waitlist control at all. Until somebody opens Edit and turns it on, the third row above is what a full program does.
A single-child enrolment works out the waitlist position and tells you about it on screen, and never actually saves that number. Promoting from the waitlist uses the saved position instead, treating a child with no saved position as last in line. The Waitlist panel, in turn, ignores the saved position entirely and re-ranks everyone by enrolment date. So the number you were told, the number the panel shows, and the order used to promote can be three different things, until the first promotion renumbers the whole queue.
What is written
One enrolment record, with four values set: the child, the schedule, today's date, and the status. An audit entry is logged.
Nothing else happens. No notification is created, no email is sent, and no message reaches a guardian: PTRS has never sent a notification of any kind, anywhere in the product. No background task is scheduled either, because this module has none.
What is not checked, and why it matters
Six things a reader might reasonably expect PTRS to enforce, and does not.
| Expected | Actually |
|---|---|
| The child's age against the program's age band | Not checked. The age band is a label; the age range on the program is stored and read by nothing that makes a decision |
| The program's own eligibility rules | Not checked. A complete rule engine exists behind the scenes, and neither this check nor any screen ever calls it |
| A signed consent | Not checked. A child's enrolment is created with its consent marked Pending, and nothing ever changes it |
| A schedule conflict with the child's other programs | Not checked, and could not be. No session can be created in the first place |
| The program's own lifecycle stage or date range | Not checked |
| The child's membership status | Not checked, and it would not help even if it were: nothing after a child's record is created ever turns that status off, so it reads active on every record regardless |
The age point deserves the plainest possible statement, because it is the first question a prospective customer usually asks: PTRS enforces no age rule anywhere, for any enrolment. Members already established that for the membership record itself; this page establishes it again for a specific program. A five-year-old can be enrolled in a Senior Teens program and nothing in the product will say so.
Two other paths write the same roll
A child's enrolment can be written by three different paths, and only the one above runs the licensed-capacity check.
Bulk Enroll
Reached from the enrolment tab. It loads the schedule and the current counts once, then works through the whole list of children in one pass.
It does respect the program's own capacity and its waitlist setting, and it does save each child's waitlist position, unlike the single-child path above. It does not check the site's licensed capacity at all.
It also skips children with no message. Three separate situations, a child already enrolled or waitlisted, a record PTRS cannot match, or a program that is full with the waitlist off, are all handled the same way: the child is simply left out. The result only lists who was actually enrolled, with no entry and no reason for anyone left out. A request for twelve children that only enrols nine still succeeds, and the screen closes as if everything went through.
Promote from waitlist
Reached from the same tab. It takes a number typed by whoever is promoting, moves that many waitlisted children to active, clears their saved positions, and renumbers everyone still waiting.
It checks no capacity at all, not the site's licensed capacity and not the program's own. It has no upper bound either: a single request can move every waitlisted child to active, past both limits at once. The number box on screen limits what can be typed in the browser; PTRS itself applies no such limit.
So the protection is one path in three
Both of the unprotected paths sit on the same screen as the protected one, are reachable by every role that can reach it, and report nothing about the check they skip. A site can be pushed past its OCCL licensed capacity through the interface with no warning at all, simply by using Bulk Enroll instead of the single Enroll button.
Getting a child back out
Taking a child off a program is built correctly and completely: it finds the child's active enrolment on any of the program's schedules, marks it withdrawn, and logs the change, and nothing in the product ever calls it. There is no button, menu or control anywhere that reaches it, and there is no delete option either.
So an enrolment made in error is permanent. It keeps appearing on the child's Programs tab and on the program's roll, it keeps occupying a seat against the program's capacity, and because the site's capacity check counts active enrolments, it keeps using up licensed capacity for the whole site.
The one small mercy is that promotion and bulk enrolment both leave a withdrawn enrolment alone, so a withdrawal made directly against PTRS by someone integrating with it is durable. It simply cannot be started from the product itself.
How this differs from the Members enrolment gate
These are two different checks on two different records, and they are easy to confuse.
| Members | Programs | |
|---|---|---|
| Record | The child's membership in the club as a whole | The child's place in one program |
| What it checks | Five safety rules: two emergency contacts, an active emergency-hospitalisation consent, current immunisations, a physical within the year, and every emergency medication cleared | Six rules, of which one is regulatory: the site's licensed capacity |
| Documented in | Members | This page |
Neither one runs the other. A child can be given a place in a program without the membership gate ever having been passed, and the other way round too.
What the child's record shows afterwards
The Programs tab on a child's own record reads this module's tables directly, and is covered in Work a child's record.
One caveat belongs here rather than there: the consent status that tab displays comes from the same value covered above, which nothing in PTRS ever writes. It reads Pending for every program, for every child, forever, including after a guardian's consent has genuinely been recorded elsewhere, because recording a consent saves a separate record and never touches this one.
One tenancy note
An enrolment and the schedule it belongs to are both a slightly narrower kind of record than most of PTRS: the usual rule that hides a removed record still applies to them, and the usual rule that scopes a record to your own organisation does not.
Every check in this module reaches those records through a program or a schedule that is properly scoped to an organisation, so the practical exposure today is narrow. The one place it is not is adding a child to a cohort, which looks the enrolment up by its own identifier alone and does not check that it belongs to the cohort's own program, and nothing in the product reaches that action anyway.
Where to go next
Checked against PTRS on 7 September 2026.