Events

| Field | Value ||---|---|| Audience | public || Page type | reference || Area | sg-admin || Updated | 2026-05-14 |

The SG-Admin Events module — event records with date, location, registration.

The Events module in the admin is the per-site surface for event records — date, location, capacity, registration form linkage. Event records publish to the public site as event listings. This page is the Reference definition.

What is this for?

Read this page when you want the structural definition of the Events module.

Good use cases

• You are scoping a site that hosts events.
• You hit a "where do I add a new event?" question.

What NOT to use this for

• Step-by-step procedures — open the relevant Guide.
• Per-release shipped change — open What's New or Changelog.

How this connects to other features

• SG-Admin Overview — parent surface.
• Locations — events can reference Location records when a venue corresponds to a stored physical location.
• My Forms — events can pair with a registration form so visitor submissions become event registrations.
• Templates — public event listings render through a template the site author can adjust.

Before you start

You need the following before adding events to a site that has not used them before:

• The list of upcoming events the site will publish, with name, date range, location reference, and capacity.
• A decision on registration — collected via a paired My Forms form, or external (link to an external registration system), or none.
• A decision on listing behavior — whether past events stay visible or whether the listing filters to upcoming only.
• The image assets for the events (cover image, optional gallery). The Media Library is the right place for these.

Where to find it

The Events module lives in the admin under the content group, alongside Blogs and Pages. The exact menu position is documented in the platform's current navigation.

Steps

The steps below cover the typical first event a site adds.

1. Open Events and add a new event

Open SG-Admin, go to Events, choose Add new event. Fill the name, slug, description.

The name is the public title visitors see in the listing. The slug is the URL fragment. Keep the slug short and descriptive — it stays in the address for as long as the event remains visible.

2. Set the date range and location

Set the start date / time and end date / time. The platform uses the date range to compute the lifecycle state (upcoming, live during the window, past after end date).

Pick a location. If the site uses the Locations module and the event is at one of the stored locations, reference the location record; the location details (address, hours-of-operation context, GBP pairing) link automatically. If the venue is one-off, enter the venue as free text.

3. Configure registration

If the event needs registration, pair it with a My Forms form. Visitor submissions become event registrations and count against the capacity if capacity is set.

If the event is external-link only, enter the link in the registration field. If the event has no registration (a walk-in event), leave the registration unset.

4. Publish and confirm the listing

Publish the event. The public event listing surfaces the new event in the upcoming list. Confirm the listing reads as expected — the date format matches the site's other date displays, the location reference renders the venue clearly, the registration link or form opens correctly.

What success looks like

A site running events behaves as follows:

• Upcoming events appear in the public listing in chronological order.
• During the event window, the event status reads as live.
• After the end date, the event moves to past and remains visible (unless the listing is filtered to upcoming only).
• Registration submissions appear in the paired My Forms form; capacity counts down as submissions arrive.
• Linked locations stay in sync — if location hours or address change in the Locations record, event displays referencing that location reflect the change.

What to do if it does not work

• The event does not appear in the public listing. Confirm the event is published, not draft. Confirm the listing is not filtered in a way that hides upcoming events.
• The registration form is not collecting submissions. Confirm the form is published and that the form action is correctly paired to the event.
• Capacity is wrong. Capacity counts down from the configured cap as submissions arrive. If submissions exist before capacity was set, the count may need a manual reconcile.
• The date display looks wrong. Confirm the site's time zone setting matches the time zone of the event location.
• Past events disappear when they should stay visible. The listing is filtered to upcoming only; switch the filter or expose a past-events archive.

---

Definition

An event record administers one event. Each carries name, slug, start / end date, location reference (or free-text venue), description, capacity, registration form linkage, and lifecycle state (upcoming / live / past).

Purpose

Define the Events module as a Reference layer.

Scope

Covers event record, registration linkage, lifecycle. Does not cover per-step procedures or per-release shipped change.

---

Event record + lifecycle

Records flow upcoming → live (during the event window) → past (after end date). Past events typically remain visible in archive views.

---

Registration

Events can pair with a My Forms form record for registration. Submissions to the form become event registrations and count toward capacity.

---

Constraints and boundaries

Events is a Reference area for event record management.

Do not use for: per-step procedures (Guides), per-release shipped change.

Public boundary

Public-safe.

---

Examples

Example 1 — Operator schedules a launch event

Operator adds event with date, location reference, registration form. Public site lists the event; visitors register via the linked form.

Example 2 — Operator monitors registration capacity

Operator reviews registration count, capacity threshold reached triggers manual decision (close registration or expand capacity).

Example 3 — Operator archives past events

Past events remain visible by default; operator filters list to upcoming-only when planning.

---

Documentation guidance

Use this page as the structural definition for the Events module.

---

Reading order

Open this page when scoping event-driven content workflows.

---

Related reading

• SG-Admin Overview — parent.
• Locations — venue references.
• My Forms — registration forms.

---

Vocabulary cross-reference

• Event record is one event.
• Registration form is the My Forms form paired with the event.
• Capacity is the per-event registration cap.
• Lifecycle state is upcoming / live / past.

---

Maintenance discipline

When Events module changes across releases, update this Reference.

When the lifecycle states change (new states added, transitions altered), update the "Event record + lifecycle" section.

When the Locations module relationship changes (new sync rules, new linkage fields), update the cross-link in "how this connects to other features".

---

Governance — events as time-bound public objects

Events occupy a category that ordinary pages cannot. A page has the same meaning yesterday, today, and tomorrow; an event's meaning shifts as time moves around it. The platform preserves the distinction deliberately.

An event is the occurrence body. It is not "a page with a date on it". Treating it as the latter loses the operational meaning — the listing behavior, the lifecycle state, the registration cap, the venue linkage. The Events module exists so the site can manage occurrence-centered records without forcing them into the wrong shape.

Where a record could technically be displayed as a page (a one-off announcement with a date), prefer Events when:

• The visitor experience depends on whether the event is upcoming, live, or past.
• The site needs registration tied to capacity.
• The venue is one of the site's Locations and the linkage should stay in sync.
• The listing should sort and filter by date automatically.

Prefer Pages when:

• The record is informational and does not change behavior based on date.
• No registration is needed.
• No venue linkage matters.

Recurring events

For a series of repeated events at the same time (weekly classes, monthly meetups), the platform supports the pattern by duplicating the event record with the new date rather than treating recurrence as a single record. The reason is the lifecycle state — each occurrence has its own upcoming / live / past state and its own registration cap. A single record with a recurrence rule would have to model multiple states at once, which obscures the per-occurrence registration counts.

For very high-frequency series, a Templates author can build a series template that produces the duplicated records cleanly.

Past-event archive

The default listing behavior keeps past events visible. Two reasons:

• Visitors searching for "what happened at the event" expect the page to remain.
• Search engines index event pages; deleting them after the fact breaks inbound links.

If the site prefers an upcoming-only listing, the listing filters to upcoming while the records themselves stay. The records remain discoverable through search and direct links.

Time zone discipline

Event dates and times are interpreted in the site's configured time zone. If the site serves a multi-region audience, the listing renders the time the event happens at the venue, not the visitor's local time. Visitors travelling to the event know the local time; visitors planning around it from elsewhere may want to confirm the conversion separately.

Where an event is online and intended for multiple time zones, name the time zone in the event description. The platform does not auto-convert to the visitor's local time.

## Related reading

Topic
SG-Admin
Locations
My Forms