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

# Create an event

> Create an event inside a Business Unit, choose where it publishes, and understand what the start date controls.

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

<Steps>
  <Step title="Open the Business Unit">
    Switch to the Business Unit that will run the event, then go to **Events**.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Note>
  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".
</Note>

## 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:

<CardGroup cols={2}>
  <Card title="The Business Unit's portal" icon="building-2">
    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.
  </Card>

  <Card title="Its own standalone portal" icon="globe">
    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.
  </Card>
</CardGroup>

<Warning>
  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.
</Warning>

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](/en/events/event-page) for how portals, themes and the public URL fit together.

## Event status

An event is always in one of three states:

| Status        | Meaning                                                                                                                                                          |
| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Draft**     | Invisible outside the Business Unit. The public page and registration links return "not found" — a draft is indistinguishable from an event that does not exist. |
| **Published** | The event has a public page and takes registrations.                                                                                                             |
| **Archived**  | Retired. No public page, no new registrations; records are kept.                                                                                                 |

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.

<Tip>
  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.
</Tip>

## 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

<CardGroup cols={2}>
  <Card title="The event page" icon="panel-top" href="/en/events/event-page">
    Portals, themes, the public URL and attendee accounts.
  </Card>

  <Card title="Ticket types" icon="ticket" href="/en/ticketing/ticket-types">
    Define how people register — capacity, waitlist, sale window.
  </Card>
</CardGroup>