Skip to main content
Every event belongs to exactly one Business Unit — the team whose members, roles and content it lives with. Creating one takes a name and a few timing details; everything else is configured afterwards on the event’s own pages.

​
Create the event

1

Open the Business Unit

Switch to the Business Unit that will run the event, then go to Events.
2

Click Create event

Give it a name (for example “Annual Partner Summit”). The event is created as a draft — it is not public until you publish it.
3

Set the schedule

Choose the start and end times and the event’s time zone. Times are always local to the event, in that time zone — an enterprise event’s audience is rarely all in one place, so the zone is stored explicitly rather than guessed.
You can create an event without a start time and fill it in later, but publishing requires a start time — a public page cannot say “sometime”.

​
Choose where it publishes

An event publishes through a portal — a public site with its own web address, its own attendee accounts and its own theme. At creation you choose between two homes:

The Business Unit's portal

The default. The event appears under the Business Unit’s public site, and attendees who registered for the unit’s other events use the same account here.

Its own standalone portal

The event gets a portal of its own: its own address, its own attendee accounts, no visible relationship to the Business Unit or its other events.
This choice locks after the first registration. Moving an event between portals afterwards would mean migrating every attendee’s account to a different login realm — so the platform refuses the change rather than attempting it. Decide before you open registration, not after.
Standalone is about the public face only. Inside the console a standalone event is ordinary Business Unit content, managed with the same roles and permissions as any other event. See The event page for how portals, themes and the public URL fit together.

​
Event status

An event is always in one of three states: You publish and unpublish from the event’s Event page section. Draft is the safe default: build the whole event — ticket types, agenda, forms — and nothing is visible until you decide it is.

​
The start date and the agenda

The agenda is scheduled relative to the event’s start date: a session’s day is “day 1”, “day 2” and so on from that anchor. Two consequences:
  • You cannot add agenda sessions until the event has a start date.
  • Changing the start date clears the entire agenda. The console asks you to confirm (“Change date and clear agenda”) before it does — moving an event by a day would otherwise silently reschedule every session to a day nobody intended.
Settle the start date before building the agenda. If the date is genuinely uncertain, build ticket types, the registration form and the event page first — none of those are anchored to the date.

​
Rules to know

  • One event, one Business Unit — ownership never changes.
  • Draft events are invisible to the public, always. There is no preview link that leaks.
  • The portal choice (Business Unit portal vs standalone) locks at the first registration.
  • Publishing requires a start time; changing the start date later clears the agenda after an explicit confirmation.
  • All ticketing is free today — paid ticketing is coming, and everything you configure now carries over unchanged.

​
Next steps

The event page

Portals, themes, the public URL and attendee accounts.

Ticket types

Define how people register — capacity, waitlist, sale window.