Event & Festival Data Model

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

Core hierarchy

Festival
Festival day
Event
Event slot
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.

An event type is Workspace-owned configuration selected before an event is created. It has a stable key, label, and icon and stores the event and slot form layout copied from its starter template. Its base category connects it to versioned slot and admission policy. Retiring a type removes it from new-event selection without detaching existing events.

Category contract

A category contract is the versioned policy shared by event types built from the same base category. It assigns stable slot roles and controls their minimum and maximum counts, default creation, publication requirements, admission, capacity scope, booking policy, and public visibility. It also stores custom-slot, relation, presentation, and reservation-default rules.

Each base category can have one draft and one active contract. New events record the active contract version when they are created; activating a later version does not rewrite existing events.

Event

An event is the parent record for scheduling and reservations.

Main fields:

title
slug
event type
recorded category contract
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
allow waitlist
some event types also expose required volunteers and a counts-toward-required-training flag

Notes:

Effective presentation rules can source the displayed title and cover image from the event, building, or artist. Event-level overrides apply only when those rules allow them.
Slot requirements come from the recorded category contract. It can require named role slots, cap their count, and allow or reject additional custom slots.
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.
Reservation availability and slot selection are derived from the effective slot-role admission rules.
Events can also define custom registration-form fields for the public reservation page.
Event required-volunteer counts roll up into the festival's volunteer coverage.

Event slot

Slots are child records under one event.

Main fields:

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

Behavior:

A role-backed slot uses the role label as its displayed title and cannot store a separate title. Custom slots use their own title.
The recorded category contract can define minimum and maximum counts per role and require start or end before publication.
A slot role's admission is none, registration, tickets, or mixed; public reservation availability is derived from that value.
A slot's own capacity overrides the event capacity. Without an override, the event capacity and its booked and waiting counts are shared across the relevant sibling slots.
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.

Event assignment

Links a Workspace user to an event and optionally to the parent festival.
Drives the assigned-volunteer count on festival overviews.
The festival volunteer timeline groups assignments by creation date in Einblick, not by event date.

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.