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

​
Build one

1

Create it

Click New automation and just name it — the trigger and the flow are both set on the canvas.
2

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

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

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.

​
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.
  • 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.
About housing — see 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…; is in one of these cohorts…; email domain is…; is staff of one of these exhibitors….

​
Lifecycle and runs

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