Two ways in. Send a scenario (below left) fires a lifecycle moment on synthetic data — use it to check that the templates render and the emails arrive. Fire a real record (below it) fires the same moment for an existing reservation or day pass, with that record's own guest and data — use it to check what a given booking actually sends.
The scenario form fires one reservation lifecycle moment at the real Customer.io workspace:
the person identify (profile + active_* mirror), the lifecycle event, and —
when you tick the box — the transactional email for that moment.
Everything is synthetic: the profile is guest_99xxxx, it is flagged
test_profile = true for Customer.io's test audience, and the email goes only to the address you
type here — so no real guest is ever touched and no live automation picks the data up.
The guest, reservation (CIO-99xxxx) and day pass behind that id are saved in the PMS,
so you can reuse the same guest id later and inspect the very same records.
Runs the production path for an existing record: the same core fields, traits and event names the
queued jobs build — only synchronously, so you see every payload and response.
This writes to the real guest's Customer.io profile, so the email half keeps every
gate (app key, CUSTOMERIO_TRANSACTIONAL_ENABLED, the QA recipient override and the
never-email-twice row). A moment the guest already received is reported, not re-sent — replay
without limits is what the synthetic form above is for.
| Track credentials | missing |
|---|---|
| App API key (transactional) | missing |
| Region | us |
| Integration connection | enabled |
| Automatic syncing (observers) | off — only this page sends |
| Transactional gate | off |
| Automatic sending to guests | off |
| Forced recipient (QA) | — |
| booking_confirmation | 2 |
|---|---|
| reservation_modification | 3 |
| cancellation_confirmation | 4 |
| day_pass_confirmation | 30 |
| day_pass_modification | 31 |
| day_pass_cancellation | 32 |