Skip to main content
An automation runs when something happens in the event — a registration confirming, an order remaining unpaid, a hotel confirming a stay. The flow is drawn on a canvas: wait, check a condition, send email, grant a perk. Once active, it runs without further action.
An active automation sends real email every time its trigger fires. The activation dialog names the trigger.

​
Build an automation

1

Create it

Choose New automation and name it. The trigger and the flow are set on the canvas.
2

Pick the trigger

Select the trigger card and choose what starts the flow. Registration and order triggers can be limited 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

Choose Activate. The flow must be complete first — one trigger, everything wired, no loops, at least one email 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 start time scheduled.

​
Triggers

About a person or an order — these accept the ticket-type filter:
  • Attendee added from the console — someone was registered 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 reminders. See Orders.
  • Before the event starts — the clock, not a person. Fires once, at a chosen time before the event start (hours or days), and creates one run per registration. Choose which statuses get a run; empty means confirmed registrations only.
About a company — the ticket-type filter does not apply; email goes to the exhibitor’s contact address; 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 at the moment the step runs. 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 page is the audit trail.

​
Rules

  • Active means locked. Pause before changing the trigger or the flow.
  • Pausing or archiving cancels waiting runs. A run parked on a delay does not fire later under a stopped automation.
  • Emails come from 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 makes that step a team notification instead of an attendee email.
  • Perk grants are additive and follow 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 are archived, not deleted. Runs remain the record of what was sent.