Events

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

Related docs: Event & Festival Data Model, Festivals, Festival Days, Buildings, Contacts, My Connections, System Settings Integrations

What an event contains

• Event record: title, slug, category, status, visibility, description, cover image, internal notes.
• Context: optional links to a festival, festival day, building, artist contact, and address.
• Booking and staffing rules: reservation capacity, ticket capacity, waitlist, slot requirement, 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 category-dependent Schedule, Reservations, and Registration form tabs.

The main list supports:

• Table and grid views
• Search
• Filters for category, status, and visibility
• Bulk delete
• Creating a festival from selected events when the Festivals feature is enabled and you can create festivals

Create and edit flow

1. New events start with category selection.
2. The selected category decides which fields and tabs are visible.
3. Some categories force single-slot mode. Others allow multiple slots.
4. The category cannot be changed after the event has been created.

Important behavior from the form:

• If the title is empty, selecting a building or artist can prefill it.
• 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.
• At least one slot is required by the form.

Available categories depend on the workspace's allowed event-category list. Administrators can enable exactly the categories a workspace should use, so there is no separate basic/full event mode anymore. Festival-related list columns and bulk festival creation appear only when the Festivals feature is enabled.

Fields and rules

General

• Title is required.
• 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.
• 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 real time blocks.

• Each slot has start and end.
• End must be after start.
• allDay hides time-specific input in the form.
• 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.

Booking

These fields live on the event:

• Require slot for reservation forces reservations to choose a slot.
• 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.
• Some categories also expose Required volunteers and Counts toward required training for staffing and training planning.

The schema also contains allowReservations, but the current event form does not expose it.

Sales

• 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.

Detail tabs

General tab

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

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

Schedule tab

The Schedule tab only appears for categories that keep a separate slot view. Single-slot categories 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. Deleting a slot cancels reminders and removes the slot from connected Google Calendars.

Reservations tab

The Reservations tab only appears for categories that support reservation 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.

Registration form

The Registration form tab appears for reservation-enabled categories.

• 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.

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.
• 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 sender account and templates configured in System Settings → Events.

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 in practice, users need their own Google/device setup in My Connections. Workspace-wide providers are managed in System Settings Integrations.

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 for events that are no longer both published and public.