Composite courses: multi-part classes sold as one

What does the composite course capability do?

Plenty of real programmes are not a single class. A performing-arts session might combine dance, drama, and singing components; a coaching product might pair a group class with a linked practice session. Selling these as separate bookings creates orphaned places and mismatched registers; flattening them into one class loses the structure staff plan around.

• Parent and components. A composite course is a parent session with component sessions beneath it, each carrying a label and an explicit sort order.
• One enrolment. Customers enrol on the parent. There is no risk of a child booked into one component but not another, because the components are not bookable products in their own right.
• Inherited scheduling. Components inherit the parent’s timetable and settings, so the parts stay aligned through term calendars and skip dates without duplicate administration.
• API-managed. Adding, updating, and removing components are first-class API operations under the parent session, so the structure is available to every channel, not just one admin screen.

How it fits the rest of the engine

Composite structure composes with the platform’s other scheduling machinery rather than sitting beside it. Occurrences are still generated per date, capacity and counters still work per occurrence, and attendance registers still record against the specific dates delivered. The composite layer only changes what is sold and how the parts relate.

Why it matters

Multi-part programmes are common in exactly the sectors that outgrow generic booking tools: performing arts, activity camps, structured coaching. The workaround in a flat system is either double data entry or a naming convention someone has to police. Modelling the structure natively means the product sold matches the programme delivered, which is the standard the Booking Engine holds across its scheduling model.