The Waitlist Joined trigger fires whenever a customer adds themselves to the waitlist for one of your experiences. Use it to react in real time — alert your team, sync the lead to your CRM, or send a personal note — without having to check the backoffice.
You'll find it in the workflow builder under the Waitlist category.
When it fires
The trigger fires once per join, immediately after the entry is saved. Specifically, it runs when:
A customer submits the Join Waitlist form on the booking widget.
A waitlist entry is created via the public API.
It does not fire when:
An existing entry changes status (Notified, Claiming, Converted, Expired, Cancelled, Removed). Those are downstream events — this trigger is only about the initial join.
A duplicate join attempt is rejected (the customer is already on the list for that date).
The waitlist is full and the join is refused.
If your workflow needs to react to status changes after the join, build it on top of the booking events (e.g. Booking Confirmed) instead.
What you can do with it
Some workflows that work well on this trigger:
Slack / Teams alert — post a message to your operations channel the moment a popular date starts collecting demand.
Internal email digest — notify the experience owner, so they can decide whether to add another departure.
CRM sync — push the customer to HubSpot, Pipedrive, or Attio with a "waitlist" tag and the experience details.
Personalized outreach — if the position on the waitlist is 1 or 2, send the customer a personal thank-you and a heads-up that you're working on more capacity.
Demand tracking — log every join into a Google Sheet or BI tool to spot trends across experiences and dates.
Available variables
When the trigger fires, your workflow has access to the following variables. Reference them in actions using the {waitlist.…} syntax.
Variable | Description |
| Internal ID of the waitlist entry |
| ID of the availability the customer joined |
| ID of the experience |
| Name of the experience |
| Start time of the availability (ISO 8601) |
| Internal customer ID |
| Customer's full name |
| Customer's email |
| Customer's phone (may be empty — phone is optional on the join form) |
| Total number of guests across the customer's guest mix |
| The customer's position in the queue at the moment they joined (1 = front of the queue) |
| Timestamp of when they joined (ISO 8601) |
Note: customer_phone can be empty. If your workflow sends SMS or calls a service that requires a phone number, gate that action with a condition on {waitlist.customer_phone} not being empty.
Example: Slack alert when waitlist demand picks up
A simple workflow that posts a one-line message to Slack every time someone joins:
Trigger: Waitlist Joined
Action: Send Slack Message
Message:
:hourglass: {waitlist.customer_name} just joined the waitlist for *{waitlist.product_title}* on {waitlist.availability_from} — they're #{waitlist.position} for {waitlist.total_guests} guests.
That's enough to give your operations team an instant pulse on which dates are overheating.
Example: VIP follow-up
Use a condition to single out high-value customers and trigger a personal touch:
Trigger: Waitlist Joined
Condition:
{waitlist.customer_email}contains your VIP domain (e.g.@partner.com)Action: Send Email — internal, to your account manager, with the customer's contact details and the experience name.
Tips
The position is captured at join time. If you store it later — for example, in a CRM field — keep in mind it will drift as people ahead in the queue convert, expire, or are removed. Treat it as "where they were when they joined," not their live position.
One trigger per join, even on retries. If a customer's first attempt errors at their end and they resubmit, only the successful join fires the trigger. You won't double-fire from network hiccups.
The trigger costs 1 credit per execution. Conditions inside the workflow don't consume extra credits; only the trigger and credit-bearing actions do.
Test it with the latest entry. When you click Test Run in the builder, the trigger pulls the most recent waitlist entry in your tenant. If you don't have one yet, ask a teammate to join a sold-out date on a staging widget and run the test again.
Troubleshooting
The trigger never fires when I join the waitlist myself.
Make sure your workflow is Active (not Draft or Paused) and that the trigger is saved with no validation errors. Also confirm the experience you tested on actually has the waitlist enabled — joins on disabled experiences never happen, so the trigger has nothing to react to.
The customer phone is missing in my action.
The phone field is optional on the public join form. If your action depends on it, add a condition that gates the branch on {waitlist.customer_phone} being present, or capture the phone via a follow-up workflow on Booking Confirmed instead.
The customer name comes through as a generated string.
This means the customer was matched to an existing record by email but no name was on file. The waitlist join uses firstOrCreate keyed on email — if a stub customer already exists, the new name from the form isn't applied. Edit the customer in the backoffice to fill in the proper name.