Documentation /Workflow
Every trigger
A trigger is the thing that happened. Some carry a booking with them, and so know the customer; some carry only the event.
Bookings
These fire once per booking, so the message can be addressed to a person.
| Trigger | Fires when | Filters |
|---|---|---|
| Booking is created | A booking is made, on the site or by hand | Booking status |
| Booking status changes | Its status moves | New status |
| Attendee is checked in | A code is admitted at the door | — |
| Payment is received | Money is recorded against the order | Payment type, Payment method |
| Booking is refunded | Money goes back | Refund type |
| Event starts — for each booking | Planned, relative to the start | — |
| Event ends — for each booking | Planned, relative to the end | — |
| Event date is canceled — for each booking | A date is called off | — |
| Event date is reopened — for each booking | A cancelled date comes back | — |
Events
These fire once per event or date, not per person. Use them for your own team: there is no customer to address.
| Trigger | Fires when | Filters |
|---|---|---|
| Event starts | Planned, relative to the start | Event status |
| Event ends | Planned, relative to the end | — |
| Event is created | A new event is saved | — |
| Event date is canceled | A date is called off | — |
| Event date is reopened | It comes back | — |
Customers
| Trigger | Fires when |
|---|---|
| Customer is created | Somebody books for the first time |
Waiting list
A paid feature.
| Trigger | Fires when |
|---|---|
| A waiting list place is offered | A place comes free and is offered to the front of the queue |
This one matters: the offer is useless unless it reaches the person, and this is what sends it, carrying the claim link and its expiry.
Filters
Where a trigger has filters, they narrow it without a second workflow. "Payment is received" filtered to Cash tells the desk about cash and stays quiet about card payments.