How It Works — Children and Rooming¶
Who this is for: reservations consultants, camp and revenue managers, and anyone asked why a booking with children behaves differently — or why a room they just filled in emptied itself.
Written from the application's own logic. Anything the system does not state outright is marked (inferred) and worth confirming with the development team.
The one-paragraph version¶
Three separate rule sets share the word "children", and they do not talk to each other. Camp admission asks whether a child of that age may be at the camp at all, using fixed ages built into the code. Rooming asks whether this child may be in this room with these people, using age bands configured per option — and where those bands are left blank, the rule switches off. Charging is configured somewhere else again, and its "must share with adults" setting is a price rule that nothing enforces. A child can therefore end up alone in a room with nothing but a warning.
Camp admission¶
Every camp carries one setting:
| Setting | Meaning |
|---|---|
| No children | children under 17 are refused |
| Infant friendly | infants under 6 considered |
| Teens allowed | children 6 to 12 are the ones tested |
| Children allowed with private activities | children 6 to 12, with a private activity vehicle |
| Children only no P. Act. required | as above, without the vehicle |
| Unknown | treated the same as infant friendly in the logic |
The ages here are fixed in the code, not configured: under 17, under 6, and 6 to 12. Changing a camp's age policy in master data does not change those boundaries.
Refusal shows as an availability status captioned "Age restrictions apply".
Two things to know:
- A sole-use booking skips the age check entirely. If the whole camp is taken, nobody's age is tested.
- "Children allowed with private activities" does not size the vehicle requirement to the children. How many private vehicles a booking is entitled to is worked out from room counts, total guests and camp class — plus a hard-coded list of camps. The child policy decides whether a vehicle is needed, not how many (inferred).
Rooming: who may share a room¶
Capacity per room type comes as four numbers: normal adults, normal children, normal guests and maximum guests. Against those, the system counts the guests in the room in three buckets, not two:
- adults;
- children who count as adults — a child whose age reaches the option's "adult age from";
- children.
That second bucket is where most surprises come from. The consultant is told:
"Please be aware N of the children in this room are considered adults at this supplier"
If the option's age bands were never filled in, every child counts as an adult. The "adult age from" defaults to zero, and every age is at least zero. That single blank makes a family room look full of adults.
Exceed a count and what happens depends on whether the booking configuration has "max pax allowed" set:
| With max pax allowed | Without | |
|---|---|---|
| Over normal adults | warning: "Too many adults in the room." | the room is emptied |
| Over normal children | warning: "Exceeded normal children." | the room is emptied |
| Over max guests as well | warning: "Max pax exceeded." | the room is emptied |
"Emptied" is literal. On the room-selection screen the adults, children, staff and the guest names are all cleared. The screen has not glitched — the rooming was rejected and reset. At quote time the same checks only warn, because the sweep must not destroy a booking being priced.
There is also a plain consistency check first: the number of guest names attached to a room must equal the adults + children + staff you typed, or nothing else is checked at all — "You have not roomed your guests correctly…"
A child on their own¶
Never blocked. Three different warnings, and which one you get depends on the camp's booking method and whether the supplier allows a third bed in a room:
| Situation | What happens |
|---|---|
| Not a Wish-managed camp | "Please be aware, that on the ground, children may not be allowed in a room on their own." — booking continues |
| Wish camp, supplier allows triples | "…we assume there is space in another room for this child (not already using max pax)." — continues |
| Wish camp, supplier does not allow triples | "…we cannot assume this child will be allowed in another room as this supplier does not allow triples." — and the children are removed from that room |
Every case is written to the booking's history as a room-allocation warning, so the decision is auditable even though nothing was refused.
The age floor per room¶
Separately, the youngest child in a room is compared with the option's configured child age. Too young:
"You have a child that is younger than the allowed age policy for this room. You may not be allowed to book this room, unless you get special permission…"
This check is skipped when the child policy has been overridden, when the booking is sole use, or — importantly — when the age bands are blank. Three of its four tests are "has anyone configured this", and each unconfigured answer means "allowed".
Overrides¶
Two, at different levels:
- On the room configuration — a toggle. Pressing the same button again withdraws the override.
- On the booking line — one-way. Nothing in the system turns it back off.
Both are logged on the booking as "Child policy overridden" with the user's name. Neither microflow checks who you are; whether the button is limited to managers is page security, which the development team should confirm.
An override copied with a booking survives the copy.
Ten children per room on screen, five through the API¶
The consultant's dropdown offers no children or 1 to 10. The partner API accepts at most five ages per room. A ten-child room typed by a consultant is fine; the same room sent by a partner system loses everything past the fifth child.
Where "this party has children" comes from¶
The flags the rules read — is this guest a child, does this party contain children, how many children are in family rooms versus standard rooms — are recomputed by whichever flow last touched the pax numbers. Fourteen different flows write "party contains children", each from its own starting point: the wizard's pax dropdowns, the partner API, booking copies, trip templates and the create-from-availability screens.
(inferred) There is no single owner, so a path that changes guests without recomputing leaves the flag stale. If a booking behaves as though it has no children, check the flag before checking the rules.
Partner bookings behave differently¶
Bookings arriving through the partner API send children as up to five ages per room rather than as named guests. Each age must be present and greater than zero, or the booking is rejected.
The ceiling is five, and it is silent. A room asking for six children is accepted, but the sixth age is never validated and no sixth child record is created. Anyone integrating should treat five as the maximum per room.
What to check when something looks wrong¶
| Symptom | First thing to look at |
|---|---|
| Family room says too many adults | the option's "adult age from" — if blank, children are being counted as adults |
| Child of a given age allowed where you expected a refusal | admission uses fixed ages (under 17 / under 6 / 6-12), not the configured bands |
| Room emptied itself in step 2 | a rooming rule failed without "max pax allowed" set |
| No age rule seems to apply | the option's policy record is probably blank, which disables the rule rather than tightening it |
| Sole-use booking ignores child rules | by design — sole use bypasses admission and the age floor |
| Child priced as free but roomed alone | "must share with adults" is a price rule; nothing enforces it as occupancy |
Glossary¶
| Term | Meaning |
|---|---|
| Required room | a room the consultant has asked for, with counts of adults, children and staff |
| Normal vs max | the comfortable occupancy of a room type, and its absolute ceiling |
| Max pax allowed | permission recorded on the booking to exceed normal occupancy |
| Children as adults | children old enough, per the option's policy, to occupy an adult's place |
| Sole use | the whole camp booked exclusively; bypasses the child checks |
| Triples | whether a supplier permits a third bed in a room |
| Rooming list | the guest-name document sent to a camp — a different subject from these rules |
Where the detail lives¶
Children and rooming — developer reference has every node number and the twelve traps. Regression suite has the cases to test.