Events

Events are the operational record for scheduled programs, performances, open-house items, and reservation-based appointments.

What an event contains

Event record: event type, title, slug, status, visibility, description, cover image, and internal notes.
Context: optional links to a festival, festival day, building, artist contact, and address.
Admission and staffing rules: registration capacity, ticket capacity, waitlist, optional linked registration form, required volunteers, training flags, and sales windows.
Slots: time blocks under the event. A slot can override the event building, define its own capacity, presenter, internal notes, and sales window.
Reservations: separate records linked to the event and optionally to a slot.

The backend schema also includes ticket types, reservation items, and orders. Those records exist, but the current event screens in apps/web do not provide dedicated management for them.

Where you work with events

Open Events for the main list.
Create an event from the main page, from a festival's Events tab, or from a building's Events tab.
Open an event to get the always-on General tab plus type-dependent Schedule, Reservations, and Registration form tabs.

The main list supports:

Table and grid views
Search
Filters for event type, status, visibility, festival, and date range. The date filter matches an event when its festival day is in the range or any slot overlaps it.
Bulk delete
Creating a festival from selected events when the Festivals feature is enabled and you can create festivals

Exports use the same filtered event IDs, including the festival and slot-overlap date filters, so the file matches the visible result set.

Create and edit flow

New events start with an event-type picker. Types are grouped into those with a programme and single-entry types; each card shows its icon, color, defining relation, and admission mode. A type is disabled when one of its required Workspace features is unavailable.
If the type is defined by a building or artist, choose that relation next. The preview shows the title and image the event will inherit. You can leave it empty while preparing a draft, but it must be resolved before publication.
The type supplies the stored form layout and base category. The active category contract for that base category supplies the versioned slot, admission, and presentation rules recorded on the event.
The event type cannot be changed after the event has been created.

Important behavior from the form:

An event type can inherit the event title and cover image from the selected building or artist. When the type permits an override, More / Presentation overrides lets you enter an event-specific title or image instead.
Event-owned Title and Description support language variants. New values use the Workspace content language as their source. An inherited title remains owned by the selected building or artist unless you use an allowed event override.
The slug is generated from the title until you override it manually.
Selecting a festival day automatically sets the parent festival.
Changing the festival clears an incompatible festival day.
If the event is opened from festival-day context, the first slot inherits that day.
Required role slots are created automatically from the active category contract. Types without programme slots do not require one.

Available event types are managed in Workspace Settings → Events. A retired type disappears from new-event selection but stays linked to its existing events. There is no separate basic/full event mode. Festival-related list columns and bulk festival creation appear only when the Festivals feature is enabled.

Event types, category contracts, and slot roles

An event type gives the Workspace its own name and stable key for a stored form layout. Several types can use the same base category and therefore share its active category contract.

Each configured slot role has a stable key and a visible label. Role-backed slots display that label and cannot carry a separate title.
Category-contract rules define the minimum and optional maximum number of slots per role. Required slots cannot be removed, and the form only offers additional role slots while the maximum allows them.
A contract can allow or reject custom, untyped slots. Custom slots require their own title.
Start and end can be required only when publishing, so a draft can be prepared before its final schedule is known.
The recorded contract also carries presentation sources, relation requirements, booking behavior, and per-role admission, capacity, and public-visibility rules.

Each event records the active contract version used when it is created. Activating a later draft affects new events; existing events keep their recorded version when edited.

Workspace settings managers maintain event types, contracts, and slot roles in Workspace Settings → Events.

Fields and rules

General

Title is required unless the effective presentation rules inherit it from the building or artist.
Slug is stored on the event, but the current public share link uses the event ID, not the slug.
Status uses the standard lifecycle: draft, published, archived.
Visibility controls public exposure:
- public: available on the public event page when the event is also published
- unlisted: available on the public event page when the event is also published, but intended for direct-link sharing instead of open discovery
- private: internal only
Cover image is used on the detail page and public page. The effective presentation rules can inherit it from the building or artist.
Internal notes store staff-only context on the event.
Artist links to a contact record.
Building is the default venue for the event.
Address is a manual address override stored separately from the building.
Festival and Festival day group the event inside a larger program. Festival days are selected by date.

Schedule

Slots are the event's programme records. A recorded category contract can use named roles for different kinds of slots.

Start and end are available on programme slots; the recorded contract can require either one before the event is published.
When both are present, end must be after start.
allDay hides time-specific input in the form.
A role-backed slot uses its role label as the display title. A custom slot uses its own title.
A slot can define its own building. That overrides the event-level building for that slot.
A slot can define its own capacity.
A slot can store a presenter and staff-only internal notes.
A slot can define its own sales window.

The Schedule tab on the detail page is mainly for review and deletion. Slot editing happens in the event form.

Admission

These fields live on the event:

Allow waitlist enables waitlist behavior at event level.
Capacity reservations limits the number of reservation records.
Capacity tickets limits ticket volume.
Max tickets per signup limits how many tickets one signup can request.
Reservation form can link a published form from Forms for additional public reservation questions. Attaching a form requires form read access.
Some event types also expose Required volunteers and Counts toward required training for staffing and training planning.

Reservation availability is derived from the effective slot-role admission rules. Public roles with registration, tickets, or mixed admission are bookable; none remains informational.

Sales open at and sales close at can be set on the event.
If set on the event, the UI treats them as an override above per-slot sales windows.
Slots can still carry their own sales windows for more granular control.

The edit form uses General, Programme, Admission, and Additional information tabs when those areas are part of the selected type. Admission mode is derived from the type's public slot roles: registration, tickets, or mixed shows the matching controls, while none keeps the event informational. If an existing event still has values outside its current mode, the form keeps those controls available with a notice so the stored data can be reviewed or cleared.

Each programme slot summarizes its time, effective capacity, booked count, and waiting count. A slot capacity overrides the event capacity. Without a slot override, the event capacity and its counts are one shared pool across the relevant slots.

Detail tabs

General tab

The General tab is always available. It shows the fields used by the selected event type and can include:

cover image
title
rendered slot time summary
status and visibility
description
reservation and ticket capacities
waitlist behavior
sales window
building, address, and artist
the slot schedule when the event type keeps slot details on this screen

Schedule tab

The Schedule tab only appears for event types that keep a separate slot view. Types with one fixed slot keep their timing on the General tab instead.

The Schedule tab lists slots in a table with:

title
start
end
capacity
building assignment

From this tab you can bulk delete slots when the recorded contract's minimum role counts remain satisfied. Deleting a slot cancels reminders and removes the slot from connected Google Calendars.

Reservations tab

The Reservations tab only appears for event types that support registration behavior.

The Reservations tab combines a dashboard with an admin workflow. It shows:

the reservation flow used for this event
totals for reservations, accepted, invited, waitlist, and remaining capacity
a per-slot summary when the event has slots
response sections for needs review, invited, accepted, waitlist, and declined / cancelled

From this screen, admins can add existing active Workspace members to the event from all members, selected groups, or selected members. If the event requires a reservation slot, a slot must be selected before people are added. Using Follow event flow keeps the default assignment logic for the event: invite-led flows start as invited, while waitlist-aware capacity flows accept until full and then place new people on the waitlist.

Statuses can be changed directly from the response sections, and reservations can be removed there. When 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 promote the oldest waitlist entry first.

These admin actions update reservation data only. They do not send invitation or confirmation emails, and they are separate from the visitor-facing form used on public links.

Reservation row actions include Email history for verification, confirmation, waitlist, and older reservation emails. Each entry shows sender, Reply-To address, timestamp, delivery status, and any error. Event editors without Mail permission can still resolve Acceptance unknown there by confirming the send, retrying the exact email, or abandoning it.

Registration form

The Registration form tab appears for registration-enabled event types.

It controls extra fields on the public reservation page for this event.
Supported field types are text, long text, number, and select.
Fields can be marked required and reordered.
Submitted answers are stored with the reservation and shown back in the Reservations tab.
An event can also link a published Forms form. Those questions render on the public reservation page and the submitted form response is stored separately with source event and a link to the reservation.

Public event page

From the event detail header, users can copy a public link.

The public page is available at /ev/:eventId and only shows events that are both:

published
public or unlisted

The public page can show:

Workspace branding
title
description
cover image
published slots
slot capacity and remaining spots
slot building name
for reservation-enabled events, a reservation form for visitor signups

Important behavior on the public page:

Multi-slot events ask the visitor to choose a slot first. Single-slot events preselect that slot automatically.
The reservation form always includes name and email, and Workspace-wide defaults can also require phone, show notes, and add a privacy-policy link.
Each event can add custom registration fields of its own.
If the event links a published Forms form, its questions appear after the event fields. File-upload questions must finish uploading before the reservation can be submitted.
Linked Forms questions only appear when the public visitor also satisfies that form's visibility, sign-in, and Workspace-membership rules.
When the event is full, the page either blocks new reservations or offers the waitlist, depending on the event settings.
If email confirmation is enabled, the submitted reservation holds capacity immediately and is confirmed from the emailed link.
Reservation verification, confirmation, and waitlist emails use the exact active identity selected in System Settings → Events. The identity can come from a verified sending domain, Google Workspace, or SMTP, or use the managed Einblick fallback; the fallback is unavailable until a Reply-To address is configured.
When a reservation is confirmed or no longer accepts verification, Einblick cancels any still-queued verification email so stale links are not sent.

This route now covers reservation signup and confirmation flow, but it still does not expose ticket checkout or order management.

Sync and reminder side effects

Saving slots does more than update the database:

New non-all-day slots created through the main event form schedule a default 15-minute reminder when the start time is in the future.
Slot create, update, and delete operations trigger Google Calendar sync jobs when a start time exists.
Mobile device calendar sync is triggered after slot changes.
Removing an event removes its slots, cancels related reminders, and removes synced Google Calendar copies for those slots.

To make this work, users configure their own Google accounts, target calendars, allowed Workspaces, and device sync in My Connections.

Archive and delete

Changing status to archived keeps the event record.
Deleting an event removes the event and its slots.
Bulk delete is available from the main list.
Public pages stop working when an event is no longer published, or when its visibility is neither public nor unlisted.