Skip to main content
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.

​
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.
“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.

​
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.
Renaming the event never changes its URL — links you have already sent keep working.

​
Themes

An event’s page renders with a theme, and there are three ways to get one:
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.
The event carries a theme of its own, edited independently. The portal’s theme no longer affects this page.
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.
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.
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.

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

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