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, an event-owned 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.
Attendees: invitations, public signups, direct additions, and ticket admissions linked to the event and, when required, a slot.
Tickets: admission products attached to the whole event, a specific slot, or a repeating slot role.

Checkout, orders, and buyer credentials belong to the separate Ticketing workflow. Ticket-selling events connect to it through their Tickets, Guest List, and Check-in tabs.

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, Attendees, Registration form, Tickets, Guest List, and Check-in 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. Each card shows the Workspace's label, description, 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 inherited from each source. You can leave the relation empty while preparing a draft, but it must be resolved before publication.
The type directly supplies the form layout, relations, title, image and address sources, slot rules, admission behavior, volunteer capability, and whether extra slots are allowed.
The event type cannot be changed after the event has been created.

Important behavior from the form:

An event type chooses title and cover-image sources independently, so either value can come from the event, building, or artist. For an inherited value that permits an override, open Override for this event to set a custom value. Leave it empty or choose Reset to resume inheritance. If overrides are disabled, the corresponding event field is hidden and later changes to the source record flow through automatically.
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.
For an event-owned address, input starts as one free-text line. Use Split into fields when you need structured postal fields; Einblick stores either the line or the structured form, not both. A type with a building-sourced address hides these fields and always uses the linked building's address, without an event-level override.
Selecting a festival day automatically sets the parent festival. Slots on another programme day move to the selected day while keeping their time and duration.
Changing the festival clears an incompatible festival day.
If the event is opened from festival-day context, the first slot inherits that day.
Slot changes keep the day relation in sync. An event whose dated slots share one programme day uses the matching festival day; one that spans several programme days has no single day selected.
Required named slots are created automatically from the event type. Every non-archived event has at least one live slot because all event dates are stored on slots; a type without named slot rules receives one unnamed slot.
A compact type with exactly one slot shows its date and time directly below the title instead of opening a separate programme section.

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 and slots

An event type is a self-contained Workspace configuration. Its stable key identifies it to integrations, while its label, description, fields, relations, presentation, and scheduling rules determine what users see.

Relations to buildings, artists, festivals, festival days, and addresses can be hidden, optional, or required before publication. A building or artist that supplies the title or image is always required before publication. A building that supplies the address is also required, while the separate event-address relation is hidden.
Scheduling can use one slot, a fixed set of named slots, or free-form slots. A named slot has a stable role and visible label; it can be required, repeatable, internal-only, and assigned an admission mode. It also chooses a time shape: a range with start and end, or an instant with one time, such as last entry. Role-backed slots display that label and cannot carry a separate title.
Required slots cannot be removed from an event. Additional named slots are offered only up to the type's maximum, and the type decides whether unnamed slots are allowed.
Slot rules also control publication-time timing requirements, admission, capacity scope, booking behavior, public visibility, and whether the slot needs volunteers.
Existing events resolve the current configuration of their linked type; there is no per-event contract version. A slot rule already used by an event cannot be removed.

Workspace settings managers create and edit types in Workspace Settings → Events. Slot roles are named or reused inside the type editor rather than managed in a separate workflow.

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 follows the event type. It is either stored on the event as a one-line or structured address, or comes strictly from the selected building with no event-level override.
Festival and Festival day group the event inside a larger program. A festival day is a programme date: when the festival sets a day boundary, early-morning slots can still belong to the previous date.

Schedule

Slots are the event's programme and date records. The event type can use named roles for different kinds of slots.

When a festival day is selected, every dated slot must start within that programme day. A published event in a festival with configured days cannot keep a dated slot outside them. Drafts can remain temporarily incomplete while being prepared.

A range slot has a start and end, and the event type can require either one before publication. When both are present, end must be after start.
An instant slot has one time and deliberately no end. Changing a role from range to instant clears a stale end. Manually added slots without a named instant role remain ranges.
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.
A manually added slot starts from the first dated slot's day and time. If that source is all-day, the new slot starts at 09:00 for one hour; without a dated slot, the selected festival day supplies the date.

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

Volunteers

An event type must enable Volunteers before members can be assigned. It then chooses one whole-event volunteer pool or a separate duty roster for each staffed slot.

The type defines a default signup policy: organizer-managed, open signup with immediate confirmation, or signup by request. A staffed slot can override that policy and seed a required headcount that the event can adjust.
Save a new event before assigning people. Users with event update access can add non-archived Workspace members, including managed members without sign-in accounts. Manual assignments are confirmed and can bypass self-signup limits; overlap warnings remain visible instead of blocking the organizer.
Members can sign up when the effective policy permits and can withdraw later. Approval-based signups remain Requested until an organizer confirms or declines them.
Assignment history keeps Confirmed, Requested, Declined, and Withdrawn states. Only confirmed assignments fill the required count, festival coverage, and duty-roster export.
In a per-slot roster, the same person can hold several duties on one event when they belong to different slots.
Assignment changes save immediately and independently of unsaved edits in the surrounding event form.
The Events navigation badge counts pending signup requests only for events the signed-in user may update.

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.
Registration form is created and edited from the event's Registration form tab. It uses the same question types and submission model as Forms, but belongs to the event rather than the main Forms list.
Counts toward required training remains an event-level planning flag when its type exposes the field.

The event type configures whole-event admission separately from slot-role admission. Whole-event registration does not require a slot choice; a registration-enabled slot role does. Public whole-event or slot rules with registration, tickets, or mixed make the matching controls available, while 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. Its effective admission mode combines the whole-event rule with the public slot-role rules. 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
assigned volunteers when the type enables staffing and assignments exist
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

The Schedule tab also summarizes volunteer coverage for whole-event and staffed-slot assignments, including pending requests.

From this tab you can bulk delete slots when the event type's minimum role counts remain satisfied and at least one live slot remains. Deleting a staffed slot warns before also removing its assignments. It cancels reminders and removes the slot from connected Google Calendars.

Tickets tab

The Tickets tab appears when the event type supports ticket sales. It shows capacity, sold, held, and available units in the mode currently served by the storefront.

Create a ticket for the whole event, one specific slot, or a repeating slot role. Set its price, capacity, seats consumed per ticket, maximum quantity per order, and optional parent inventory pool. The tab also shows products inherited from the festival, event type, or slot role; these are read-only here and link to their source for editing.

For each capacity pool, reserved seats can be assigned to guest-list and partner channels and released to normal sale at an optional time. Complimentary issues consume their channel reserve first; Einblick warns before they fall back to general inventory.

Guest List tab

Ticket-selling events use Guest List for complimentary admissions. Add a name with optional email and additional guests, then choose between a name-only door entry that uses no inventory and an emailed ticket tied to an admission product. Ticketed guests receive scannable passes and use the guest-list reserve before general inventory.

Before admission, staff can edit, resend, upgrade a name-only entry to a ticket, or remove it. The festival Guest List combines entries from all its events, and door staff can find a guest by name or email. See Ticketing for inventory and scanner behavior.

Attendees tab

The Attendees tab appears for event types that support registration. It gives one list for everyone attached to the event, whether they came from an email invitation, public signup, direct staff addition, or ticket admission. The summary shows accepted attendees, people awaiting a response, waitlist and declined counts, and remaining capacity. Search and filters cover status, origin, slot, and response date; a QR icon marks attendees who already have a scannable pass.

Use Add people to enter a one-off person's name or select contacts, contact groups, users, or user groups. Users with unrestricted directory read access can also select all active contacts or all active members; either bulk selection hides the individual and group picker options it already covers. With the matching create permission, the picker can create a contact, contact group, or user group and selects the new target immediately. Adding a new user opens the Workspace invitation flow; that pending member becomes selectable after accepting the invitation. Groups are expanded when you submit, and the preview identifies new people, people already on the event, and entries without an email address. Select a slot first when the event requires one.

Then choose how to add them:

Invite by email sends each eligible person a personal RSVP link. The default reply deadline is 14 days. Einblick skips duplicate targets, missing email addresses, existing live admissions, and recipients beyond the batch limit and reports the result.
Add without email puts people directly on the attendee list with the selected status: accepted, invited, declined, or waitlist when the event allows one. It does not create an RSVP link or send an invitation. An accepted addition receives a scannable pass immediately, even without an email address; other statuses receive one only after acceptance.

An invited person can accept, decline, or change an earlier response while the link is valid. Acceptance issues a scannable QR credential when capacity is available and otherwise joins the waitlist; declining revokes an active credential. From an attendee row, resend a still-pending invitation or remove the person. Removing an accepted reservation promotes the next eligible waitlist entry when applicable.

When many invitations sit unanswered, use Send reminder in the tab header or next to the "not replied yet" count in the summary. Everyone still invited receives the invitation again, worded as a reminder, in the language they were invited in; their earlier link keeps working. The sheet is prefilled from the Invitation reminder email template in System Settings → Events (or from this event's previous reminder) and lets you change the subject and text for this send only, pick a different cover image for the reminder alone, and include expired invitations — on by default, which moves their reply deadline to the end of the event or to a number of days you choose. Nobody's deadline is ever shortened. The summary shows when the last reminder went out, by whom and to how many people, and the sheet warns when that was less than 48 hours ago. A reminder that could not be sent completely is shown as such, with how many emails went out, so you can send it again; within two days, sending again reaches only the people the first attempt missed. Each person's email history lists reminders separately from the original invitation.

By default the reminder to everyone leaves out people who were mailed recently: anyone who got the invitation, a resend or a reminder in the last three days, such as guests you invited this morning or reminded by hand yesterday. The sheet shows how many that leaves out; change the period in hours or days, or switch the rule off to reach everyone who has not answered.

To remind specific people only, use Send reminder in a row's menu or select several rows and choose it in the selection bar. Both open the same sheet with the recipients fixed to your choice — nothing is sent until you confirm there — so you can try a reminder on your own address before sending it to everyone. People in the selection who have already answered, were removed, or were not invited by email are skipped and the sheet says how many. A reminder to picked people does not count as the event's last reminder in the summary, but its wording is carried over to the next sheet.

When a guest answers some other way — a phone call, or an assistant writing that they are coming — enter the answer for them with Enter acceptance or Enter decline in the row's menu, or for several selected rows in the selection bar. A dialog first says what this sets off, and nothing happens until you confirm. Entering an acceptance does exactly what the guest's own click on the invitation link would have done: they take a seat, or go on the waiting list when the event is full, and they are emailed their ticket with the QR code or, on events without a pass, the confirmation. No email is sent when the accepted-invitation email is switched off in System Settings → Events, or for a decline. For a single guest you can also enter how many people they bring, when the event allows additional guests. An acceptance can be entered for invitations that are unanswered, expired or declined; an expired one is reopened until the event ends. A decline can be entered over anything but a decline, and takes back the ticket of a guest who had accepted, so the waiting list moves up. The person's details show who entered the answer; if the guest later answers through their own link, their answer replaces it.

Reservation-backed rows also provide 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.

Check-in tab

The Check-in tab appears for event types with registration or ticket sales. It manages the event's gates and the mobile devices allowed to scan there.

Create a gate with a display name and code. You can later rename the display name without changing its code.
Deleting a gate removes it from active configuration but preserves historical scans and scanner sessions. Its former code becomes available for a new gate.
Approve a pending scanner device or revoke an enrolled device. Revocation ends its active scanner access immediately.
Scanning uses a time-limited session for one device, operator, gate, and event. Offline scans synchronize later; conflicts stay available for supervisor review.

Gate and device management follows the Admission permissions. See Ticketing for credential, refund, and scanning behavior.

Registration form

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

Adding the first question creates a published, unlisted form owned by the event. It stays out of the main Forms list and is maintained from this tab.
The full Forms builder is available, including choice, date and time, rating, consent, statement, divider, and file-upload questions as well as text and number fields.
Questions can be required and reordered. The same form appears on public signup and on an invitee's RSVP page.
Required questions are checked when an invitee accepts; declining does not require answers. File uploads must finish before signup or acceptance can be submitted.
Answers are stored as normal form submissions with source event, linked to the public reservation or invitation admission that produced them.

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.
Questions from the event's Registration form appear after the standard fields. File uploads must finish before the reservation can be submitted.
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 covers reservation signup and confirmation. Ticket checkout and buyer order access use the separate hosted /tickets/:storefrontSlug routes described in Ticketing.

A personal invitation opens /ev/rsvp/:token. The bearer link shows the event's registration questions and current invitation state, and displays the QR credential after acceptance. It stops accepting changes after expiry. By default, the effective event cover image heads invitation, accepted-pass, and guest-ticket emails as well as the RSVP page; one Workspace setting disables it, and events without a cover stay text-only. When enabled in Workspace Settings, acceptance also sends a separate pass email with the QR code and an optional PDF attachment.

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. Google sync exports readable event slots according to each connection's Workspace selection.
Google Calendar requires an end time, so an instant slot is represented there as a 30-minute block. It remains an instant without an end in Einblick.
Native device calendars receive only the signed-in member's confirmed assignments for published events. Requested, declined, withdrawn, and unassigned readable slots are not exported to the device.
A confirmed slot assignment schedules a duty reminder when reminders are enabled for that slot. Without a custom lead time, it uses 30 minutes before the duty. Changing its time or status, or withdrawing, cancels stale reminder jobs.
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.