Event & Festival Data Model

Related docs: Events, Festivals, Festival Days, Buildings, Contacts

Core hierarchy

1. Festival
2. Festival day
3. Event
4. Event slot
5. Reservation

That is the main operational chain, but not every level is required on every record.

Festival

• Groups a program across multiple days.
• Can have events directly attached to it.
• Can also have festival days attached to it.

Festival day

• Represents one calendar date inside a festival.
• Stores the day date, status, and optional description.
• Can hold many events.

In the event form, selecting a festival day auto-fills the parent festival.

Event

An event is the parent record for scheduling and reservations.

Main fields:

• title
• slug
• category
• status
• visibility
• description
• cover image
• festival
• festival day
• building
• address
• artist

Booking-related fields:

• sales open / close
• max tickets per signup
• capacity tickets
• capacity reservations
• require slot for reservation
• allow waitlist
• some categories also expose required volunteers and a counts-toward-required-training flag

Notes:

• The current form requires at least one slot.
• The current public page uses the event ID in the URL, not the slug.
• Published unlisted events still work on that public link; they are just intended for link-only sharing.
• allowReservations exists in schema, but is not currently exposed in the event form.
• Events can also define custom registration-form fields for the public reservation page.

Event slot

Slots are child records under one event.

Main fields:

• title
• start
• end
• all day
• building
• capacity
• presenter
• internal notes
• sales open / close

Behavior:

• Slot building can override the event building.
• Slot sales windows can be more specific than event-level sales windows.
• Slot deletes trigger reminder and calendar-sync cleanup.

Reservation

Reservations belong to one event and can optionally point to one slot.

Main fields:

• user
• full name
• email
• phone
• notes
• record status
• response status
• attended
• favorite
• slot
• order
• expires at
• check-in at

The current event UI uses reservations in an admin workflow, not just a passive list. Staff can add existing active workspace members to an event, optionally assign a slot, move reservations between invited, accepted, waitlist, and declined / cancelled, and remove reservations.

If an accepted spot opens up, the backend promotes the next waitlist entry automatically for the same slot when applicable. Sneak preview flows prefer favorites first; other flows use oldest-first promotion.

These admin actions update reservation data only. They do not send outbound reservation emails themselves.

Reservations can also be created by unauthenticated visitors on a published public or unlisted event page. That flow can require email confirmation, can move visitors onto the waitlist when full, stores custom field answers separately from the base reservation row, and uses workspace-configurable verification / confirmation / waitlist emails.

Other related records

Artist

• Stored as a contact record.
• Linked through the event's artist field.

Building

• Linked at event level and optionally again at slot level.
• Used for venue context and slot-level overrides.

Address

• Stored separately from the event.
• Used when the event needs a manual address instead of, or in addition to, building data.

Cover image

• Stored as a file record.
• Used on event detail and public event pages.

Public visibility rule

The public event page only returns events that are both:

• published
• public or unlisted

unlisted means the page is still reachable by direct link, but not meant for broad discovery. Slots shown on the public page are filtered to published slots.

Backend records not yet covered by the event UI

The schema also defines:

• ticket types
• reservation items
• orders
• order items

These are part of the wider event commerce model, but they are not managed from the current event admin screens described in Events.