Events App Starter · Industry version
School Event Template
Campus events without the ticketing detour — sessions, room capacity, and family registrations in code your school owns.
School events come in flocks: an open house with six tour slots, orientation across two days of sessions, a science fair with volunteer shifts. This starter handles the session structure and family-shaped registration that campus events actually need — generated as code your institution owns and hosts.
- 6 core entities
- No per-ticket fees
- Code you own
- Vibe + Governed modes
01 · The problem
Why a generic Events falls short
Campus events are rarely one gate and one room. An open house is a welcome talk plus lab tours in groups of fifteen plus department drop-ins; orientation is a two-day grid of sessions with prerequisites and clashing times. Flat ticketing collapses that structure, so families over-book tours and half the sessions run at the wrong size.
The registrant is usually a household, not an individual. One parent signs up two prospective students and a grandparent, needs to update names a week later, and expects one confirmation email — while the school needs accurate per-person counts for rooms with fire-code limits. Buyer-centric ticket flows model none of this cleanly.
And schools answer for their data differently. Attendee lists include minors, consent language matters, and IT wants student and family data on institutional infrastructure rather than scattered across a commercial ticketing platform's marketing machine. An owned system on your own domain is the shape procurement is actually asking for.
02 · Data model
The data model, adapted
Everything in the base Events starter —
eventsticket_typesregistrationsattendeescheck_inspromo_codes— plus the entities this industry actually runs on:
| table | what it holds |
|---|---|
sessions | Sub-events within an event — tour slots, workshops, info talks — each with its own room, time, and capacity. |
households | Family groupings behind registrations, so one sign-up covers several attendees with one point of contact. |
03 · Screens
Modules through the industry lens
Event pages with session pickers
01A family registering for the open house picks a tour slot and two drop-ins from a live-availability grid, and clashing times can't be selected together. Every session enforces its own room capacity — the fire-code number, not a hopeful estimate.
Household registration
02One registration carries multiple attendees under one contact, editable up to the day — a name fix or an added sibling doesn't mean a new sign-up. Confirmations and reminders go to the household once, in the language of visiting a school rather than buying a ticket.
Check-in by family, counts by room
03The lobby screen checks in whole households in one tap while session leaders see live headcounts for their rooms. Admissions gets the number that matters afterwards: which registered families actually walked the campus.
04 · In practice
Workflows it models
Open house with tour groups
01Publish the event with six tour slots of fifteen. Families self-sort into slots as they register, the waitlist absorbs the overflow, and tour guides start on time with printed-or-phone rosters that match the lobby's check-ins.
Orientation week grid
02Two days, thirty sessions, some mandatory by cohort. Students build a personal schedule from the grid; capacity and clash rules keep it feasible; advisors can look up any student's plan on the spot when they wander in lost.
Recurring series with a memory
03Monthly campus tours run as events in a series, and because history accrues in your tables, admissions can answer the real question — which visit month converts to applications — with a query, not a survey.
School & Campus Events template — frequently asked questions
Can one parent register a whole family?
Yes — registrations are household-shaped: one contact, several named attendees, one confirmation thread, editable until the event. Per-person counts stay accurate for room capacity while families deal with one simple sign-up.
Does it handle sessions with separate capacities?
Sessions are first-class: each has its own room, time, and enforced capacity, with clash detection when one person registers for overlapping slots. Open-house tours and orientation grids are the native use case, not a workaround.
Where does student and family data live?
In your database, on your infrastructure — the app is generated as code your institution owns and hosts. That keeps minors' data inside your governance rather than inside a ticketing platform's terms of service.
Is this a full student information system?
No — this runs events: registration, sessions, and attendance. Enrollment, grades, and guardians year-round belong to a student information system, and there's a dedicated starter for that built on the same conventions.
Related
Dual7 App Starters
Build your School & Campus Events on your terms
Campus events without the ticketing detour — sessions, room capacity, and family registrations in code your school owns. Describe your version to start — the output is a project you own.