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

# Automations

> When something happens in your event, run a flow on its own: a trigger, a canvas of steps, and real email going out without you.

An automation reacts to something happening in your event — a registration confirming, an order sitting unpaid, a hotel confirming a stay — and runs a flow you drew on a canvas: wait, check a condition, send an email, grant a perk. Once **active**, it runs entirely on its own.

<Warning>
  An active automation sends **real email** every time its trigger fires. The activation dialog names the trigger so you confirm exactly what you are switching on.
</Warning>

## Build one

<Steps>
  <Step title="Create it">
    Click **New automation** and just name it — the trigger and the flow are both set on the canvas.
  </Step>

  <Step title="Pick the trigger">
    Select the trigger card and choose what starts the flow (see the list below). Registration and order triggers can be narrowed to **only these ticket types**; leave the filter empty to fire for any type.
  </Step>

  <Step title="Wire the flow">
    Drag blocks onto the canvas and connect them from a card's bottom port. **Actions**: send email (a template, to the person the run is about or to a fixed address), grant perks, add to a static cohort, call a webhook. **Flow**: wait (1 minute to 30 days), and condition — a live yes/no check that branches the flow.
  </Step>

  <Step title="Activate">
    Click **Activate**. The flow must be complete first — one trigger, everything wired, no loops, at least one email sent somewhere — and everything it cites must be usable: templates existing with content and not archived, perks active, cohorts static. A countdown automation also needs the event's start time scheduled.
  </Step>
</Steps>

## Triggers

**About a person or an order** — these accept the ticket-type filter:

* **Attendee added from the console** — you registered someone by hand.

* **Registration confirmed / awaiting approval / waitlisted / rejected**.

* **Order placed / confirmed / cancelled / expired unpaid** — pair *Order placed* with a wait and the *order is still unpaid* condition for payment nudges. See [Orders](/en/ticketing/orders).

* **Before the event starts** — the clock, not a person: fires once, at a time you choose before the event's start (hours or days), and creates one run per registration. You choose which statuses get a run; empty means confirmed registrations only. The reminder-email trigger.

**About a company** — the ticket-type filter does not apply; email goes to the exhibitor's contact address, and person-bound actions are skipped:

* **Exhibitor confirmed** and **Booth assigned to an exhibitor** — see [Exhibitors](/en/exhibition/exhibitors).

**About housing** — see [Stays](/en/housing/stays):

* **Stay confirmed by the hotel** and **Guest checked in at the hotel**.

## Conditions

A condition branches the flow into **Yes** and **No**, checked live at the moment the step runs — "still unpaid after an hour" is the whole point. Checks: order is still unpaid; registration status is…; ticket type is…; holds one of these [perks](/en/ticketing/perks)…; is in one of these [cohorts](/en/marketing/cohorts)…; email domain is…; is staff of one of these exhibitors….

## Lifecycle and runs

| Status       | What it means                                                                                                 |
| ------------ | ------------------------------------------------------------------------------------------------------------- |
| **Draft**    | Being built; never fires.                                                                                     |
| **Active**   | Live — the flow runs whenever the trigger fires. The canvas is locked; **pause to edit**.                     |
| **Paused**   | Stopped. Editing is open again.                                                                               |
| **Archived** | Retired, off the list; its runs stay on record. Restoring lands on **Paused**, never straight back to Active. |

Every firing produces a **run**: who it was about, when it started, and each step's outcome in order — email sent, waited, yes/no, perks granted, skipped. The runs table on the automation's page is your audit trail.

## Rules to know

* **Active means locked.** An active automation runs exactly what was activated; pause before changing the trigger or the flow.
* **Pausing or archiving releases waiting runs** — a run parked on a delay is cancelled rather than firing later under a stopped automation.
* **Emails come from your templates.** An automation cannot activate while a send-email step cites a template that is missing, archived or has no content — see [Email templates](/en/marketing/email-templates).
* **Send to a fixed address** turns a step into a team notification instead of an attendee email.
* **Perk grants are additive** and follow the usual perk rules — see [Perks](/en/ticketing/perks).
* **Automation email is separate from the Emails page.** One-off sends are recorded there; automation deliveries live in each automation's run history.
* **Automations never delete** — archive them; their runs remain the record of what was sent.