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. Attendee admission

That is the main operational chain. Festivals and festival days are optional, but every non-archived event has at least one live slot because event dates are stored on slots. Attendee admissions remain optional.

Festival

• Groups a program across multiple days.
• Can have events directly attached to it.
• Can also have festival days attached to it.
• Can set the local time at which one programme day changes to the next. Without a boundary, programme days follow calendar dates.

Festival day

• Represents one programme date inside a festival. With a 06:00 boundary, for example, a slot at 01:00 belongs to the previous date.
• 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 and moves differently dated slots onto that programme day while retaining their times and durations. Slot-driven changes take precedence afterwards: one programme day selects the matching festival day, while slots spanning several programme days clear the single-day relation.

Event type

An event type is self-contained Workspace configuration selected before an event is created. It has a stable key, label, description, and icon and directly stores the event and slot form layouts, relation requirements, title, image and address sources, volunteer capability, named slot rules, whole-event and slot admission behavior, and custom-slot policy. A starter or blank layout is copied into the type when it is created; later behavior resolves from the stored type itself.

Types can use one slot, a fixed set of named slots, or free-form slots. Retiring a type removes it from new-event selection without detaching existing events. An unused type can be deleted.

Event

An event is the parent record for scheduling and attendee admissions.

Main fields:

• title
• slug
• event type
• 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
• volunteer-enabled event types can expose a required-volunteer count and a counts-toward-required-training flag

Notes:

• Effective presentation rules source the displayed title and cover image independently from the event, building, or artist. Event-level overrides apply only when allowed; otherwise later source-record changes flow through without storing a copied value on the event.
• The type also chooses whether the address belongs to the event or comes strictly from its building. A building-sourced address has no event-level override.
• Slot requirements come directly from the event type. It can require named role slots, cap their count, and allow or reject additional unnamed slots. A type without named roles still creates one unnamed 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.
• Registration and ticketing can be enabled for the whole event independently of its slot roles. Whole-event registration does not require a slot; slot-based registration does.
• Each event can own one published, unlisted registration form. It uses the Forms question and submission model but is authored from the event and omitted from the main Forms list.
• Volunteer-enabled events can assign non-archived Workspace members independently of reservations. Required and assigned counts roll up into the festival's volunteer coverage.
• A published event attached to a festival with configured days cannot place dated slots outside those programme days. Draft events can remain temporarily incomplete while being edited.

Event slot

Slots are child records under one event.

Main fields:

• title
• role
• time shape
• 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.
• A role can define a range with start and end or an instant with one time and no end. Legacy and free-form slots default to range; an instant ignores and clears a stale end.
• The event type can define minimum and maximum counts per role and require the applicable timing fields 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.
• A dated slot's festival day is resolved in the festival timezone using its programme-day boundary. Slot creates, edits, deletes, and calendar moves recalculate the parent event's festival-day relation.
• Slot deletes trigger reminder and calendar-sync cleanup.

Attendee admission and reservation

The attendee list is built from registration admissions. One admission identifies a person on one event and can point to a slot, user, contact, reservation, order, and scannable credential. Its source records whether the person came from an invitation, public signup, staff action, or ticket workflow; its status covers invited, confirmation pending, accepted, waitlisted, declined, expired, and cancelled states.

Reservation rows still hold signup-specific details such as phone, notes, attended and favorite flags, and email-confirmation state. Public signups and direct additions of Workspace members create or update a reservation and mirror it to an admission. A contact added directly gets an admission without a reservation. The Attendees tab combines both paths with invitation-only and ticket admissions in one view.

Staff can resolve contacts, contact groups, users, and user groups and then either send personal invitations or add the people directly with a chosen status. Entries without email and duplicate targets are skipped; invitations and direct contact additions also skip existing live admissions, while an existing member reservation can be updated. Removing an accepted reservation promotes the next eligible waitlist entry for the same slot when applicable.

Invitation claims are stored as hashes. While a personal bearer RSVP link is valid, its recipient can accept, decline, or change an earlier response. Acceptance issues a QR credential when capacity is available or moves the admission to the waitlist; declining revokes an active credential. A successful acceptance also creates one completed zero-price registration order line with payment marked not required; later acceptance of the same admission reuses it. Workspace settings can send a separate acceptance email with the QR and an optional PDF pass.

Unauthenticated visitors can create reservations on a published public or unlisted event page. This flow can require email confirmation and can place a visitor on the waitlist when full. The event-owned form produces a normal form submission with source event, linked to the reservation; an invited person's accepted answers are instead linked to the registration admission.

Other related records

Event assignment

• Links one non-archived Workspace member to an event, optionally to one event slot and the parent festival. Managed members without sign-in accounts are supported.
• Whole-event staffing has one assignment per event and member. Per-slot staffing has one assignment per event, member, and slot, so the same member can hold several duties on one event when the slots differ.
• The lifecycle is requested, confirmed, declined, or withdrawn. Only confirmed assignments fill a slot's volunteer count and the festival's coverage; the other states remain as history.
• New assignments are allowed only for event types with Volunteers enabled. Manual organizer changes save immediately and require event update access; self-signup additionally follows the type, slot, and festival rules.
• Festival limits per person and day use programme days rather than calendar midnights.
• 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.
• For an event-owned address, it can be stored as one free-text line or as structured postal fields. Expanding or collapsing the event form switches between those representations so display, export, and geocoding use one source.
• For a building-sourced address, the linked building's address is authoritative and the form exposes no override. Any earlier event address is ignored and removed the next time the event form is saved; event reads and public API projections return the building address.

Cover image

• Stored as a file record.
• Used on event detail and public event pages.
• When enabled in Workspace Settings, the effective event cover also heads the invitation email, accepted-pass email, and RSVP page. Events without a cover keep the text-only layout.

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.

Ticketing records

Ticket products, inventory pools, orders, payments, credentials, vouchers, promotions, refunds, and scan records form a separate commerce model. Ticket products do not use the ordinary Products catalogue.

Admission products can be attached to a festival, event type, slot role, event, or slot. Event editors create whole-event, slot, and slot-role tickets from the event's Tickets tab; inherited products remain owned by their source. Products are shared between modes, while their inventory pools and sales records belong to test or live mode.

The event detail manages ticket products, admission gates, and scanner devices, but not checkout or buyer orders. The hosted shop and private order pages are described in Ticketing.