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

# Core concepts

> The vocabulary Orriven is built on — organizations, business units, events, portals, registrations, attendees, contacts, orders and perks.

Orriven's console uses a small set of words consistently. This page defines each one and how
they relate. If a term on any other page is unclear, it is defined here.

## Organization

**Who signed the contract.** The organization is your company's account on Orriven: the shared
member pool, and the container everything else lives in. You can belong to several organizations
and switch between them from the console.

## Business Unit

**Who runs events.** A business unit is a team inside the organization with its own events,
its own members and roles, and its own public portal. A company might have one for corporate
events and another for field marketing — each with different people and different branding.
Every organization starts with one business unit created automatically, so a single-team company
never has to think about the layer. See [Business Units](/en/organization/business-units) and
[Members & roles](/en/organization/members-roles).

## Event

One event run by one business unit: a name, dates, a public page, and everything hanging off it —
ticket types, agenda, exhibitors, housing, emails. Events are created as **drafts** and become
visible to the public only when you publish them. See [Creating an event](/en/events/create-event).

## Portal

**A public site.** A portal is one public face: one web address, one attendee account realm, and
one theme. There are two kinds:

* A **business unit portal** — every business unit has exactly one, created with it. Its events
  publish there, and one attendee account covers everything a person booked with that business
  unit.
* A **standalone event portal** — an event that should look like it belongs to nobody gets its
  own portal: its own address, its own attendee accounts, no visible connection to your other
  events.

An event's portal is chosen when the event is created, and it **locks after the first
registration** — moving an event between portals afterward would split attendees' accounts, so
the console does not allow it.

## Registration

**One person in one event — the atom of the whole system.** A registration is what the Attendees
page lists, what capacity counts, and what perks attach to. Because enterprise events are often
free, a registration never *requires* an order: someone you key in manually on the
[Attendees](/en/events/attendees) page is fully registered with no order at all, while public
checkout always creates one.

## Attendee vs. Contact

The same person appears as two different things, on purpose:

|            | Contact                               | Attendee                 |
| ---------- | ------------------------------------- | ------------------------ |
| Belongs to | your organization                     | one portal               |
| What it is | your CRM record of the person         | the person's own account |
| One per    | email address across the organization | email address per portal |

A **contact** is the organizer's asset — your record of everyone who has ever interacted with
your organization. An **attendee** is the person's own login on one portal, where they see and
manage their registrations. The same email on two portals means two attendee accounts, always —
that separation is what keeps a standalone event genuinely standalone.

## Order

Every purchase made through public checkout — free or, later, paid — goes through an order. A
pending order holds its seats for 15 minutes; confirming it completes the registration. Today
every amount is 0. Organizers mostly read orders rather than create them; see
[Orders](/en/ticketing/orders).

## Perk

A named entitlement — "Breakfast voucher", "VIP lounge access" — defined once per event and then
attached to things. Attached to a ticket type, add-on or redemption code, a perk is **granted**
to whoever registers through it. Attached to a session or venue, it **restricts** entry to
holders. Ticket → perk → session is how gated programming works. See [Perks](/en/ticketing/perks).

## How it all fits

```
Organization
└─ Business Unit  ── members & roles ── portal (public site)
   └─ Event  ── ticket types, form, offers, perks
        ├─ Registrations (attendees)
        ├─ Agenda: sessions, speakers, venues
        ├─ Exhibition: exhibitors, booths
        ├─ Housing: hotels, room blocks, stays
        └─ Email: templates, sends, automations
```

<Note>
  Everything a person can do in the console is scoped by this hierarchy: organization role first,
  then the role inside each business unit. How that resolves is covered in
  [Members & roles](/en/organization/members-roles).
</Note>