> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orriven.com/llms.txt
> Use this file to discover all available pages before exploring further.

# The event page

> How the public side of an event works: portals, themes, draft versus published, the event URL and attendee accounts.

The **Event page** section of the console controls the public side of an event: whether it is visible, what address it lives at, and whose theme it wears. The public page is where people read about the event and register.

## Portals: the public face

Every event publishes through a **portal**. A portal is one public face, and it bundles four things that always travel together:

* one web address (a subdomain of the platform),
* one attendee account realm — who can log in there, and what they see,
* one theme root,
* one account area where attendees manage their bookings.

Each Business Unit has a portal of its own, created automatically — its public homepage lists the unit's published events. A **standalone** event has its own portal instead: its own address and its own attendee accounts, with no visible link to the operator. Which portal an event uses is chosen at creation and [locks after the first registration](/en/events/create-event).

## Publish and unpublish

The Event page shows the event's visibility and the switch:

* **Published** — the event has a public page and takes registrations. Anyone with the link can register.
* **Draft** — not visible outside the Business Unit. The public address returns "not found" until you publish, and publishing requires a start time.

<Note>
  "Not found", not "access denied": a draft event, an unpublished page and a nonexistent address all look identical from outside. Nobody can confirm a draft exists by probing links.
</Note>

## The event URL

Once published, the event's address is the portal's address plus a short public URL id — an id that is deliberately not guessable and not derived from the event's name. The Event page shows the full address with a copy button; that link is what you put in invitations and campaigns.

<Tip>
  Renaming the event never changes its URL — links you have already sent keep working.
</Tip>

## Themes

An event's page renders with a theme, and there are three ways to get one:

<AccordionGroup>
  <Accordion title="Inherit the portal's theme (live)">
    The default. The page uses the portal's theme **as a live reference** — restyle the Business Unit's portal and every inheriting event restyles with it. That is the point: one brand refresh, every page follows.
  </Accordion>

  <Accordion title="Own theme">
    The event carries a theme of its own, edited independently. The portal's theme no longer affects this page.
  </Accordion>

  <Accordion title="Copy from another event (snapshot)">
    Start an own theme by copying an existing event's look. The copy is a **snapshot** — after copying, the two are unrelated and edits to one never touch the other. This is the usual way a standalone event starts from an established design.
  </Accordion>
</AccordionGroup>

A standalone event's portal is its own, so "inheriting the portal's theme" already gives it an independent look — there is nothing external for it to inherit from.

### Draft and published themes

A theme has two versions: a **draft** you edit and a **published** version the public sees. Public visitors only ever see the published theme — editing the draft never changes the live page until you publish it. This is what makes it safe to restyle a page while registration is open.

<Warning>
  A theme is presentation only. Nothing in a theme can hide an event or gate access — visibility is the event's **status**, and access rules live on ticket types and redemption codes. "Hidden by the theme" is not a state that exists.
</Warning>

## Attendee accounts

People who register get an attendee account **on the portal**, where they can sign in and manage their own bookings. Two things follow from accounts being per-portal:

* One account covers everything a person booked through that portal — all of a Business Unit's events, if it is the unit's portal.
* The same email address on two different portals is **two separate accounts** — including a standalone event's portal run by the same Business Unit. A standalone event that shared logins with the operator's other events would leak exactly the relationship it exists to hide.

Attendee accounts belong to the attendee; your organizer view of the same person is the registration, on the [Attendees page](/en/events/attendees).

## Rules to know

* Public visitors only ever see the **published** theme and **published** events; drafts of either are invisible.
* Inheriting a theme is live; copying is a snapshot. Pick by whether you want future portal restyles to follow.
* Themes never gate access or visibility — status does.
* The event URL is stable across renames; the portal choice behind it locks at the first registration.
* Same email, different portal = different attendee account, by design.