Automation Triggers

Automations are triggered by events fired internally by the platform. Every event has the same effect regardless of which API surface created the underlying record — a lead created via the form widget, an ingress webhook, or the Connect API all fire the same table.entry.added event, and the same flows run.

Event catalog

Event	When it fires
table.entry.added	A new lead entry is created in any Lead Pool
table.entry.leadState.changed	An entry’s leadStateId changes (including the initial null → state transition on creation)
calendar.appointment.booked	A booking is created — once per shared appointment when several people are booked together (see below)
calendar.appointment.hasStarted	At the booking’s startDateTime
calendar.appointment.hasEnded	At the booking’s endDateTime
calendar.appointment.deleted	A booking is deleted

Which API fires which event

Event	Form widget	Ingress webhook	Connect API	Console UI
table.entry.added	✓	✓	✓ (POST /connect/table_entries/)	✓
table.entry.leadState.changed	✓ (initial)	✓ (initial)	✓ (POST initial + PATCH transitions)	✓
calendar.appointment.booked	✓ (when form has booking-calendar field)	—	✓ (POST /connect/calendar_bookings/)	✓
calendar.appointment.hasStarted	✓	—	✓	✓
calendar.appointment.hasEnded	✓	—	✓	✓
calendar.appointment.deleted	—	—	✓ (DELETE /connect/calendar_bookings/:id)	✓

Note

Ingress webhooks don’t book — they only create lead entries. If you need both lead and booking from a single integration, use the Connect API or the form widget (which can do both atomically).

Trigger context

When a flow is triggered by an event, the run’s context carries metadata about the source. For events fired via the Connect API, this includes:

• apiTokenId — the Connect token that performed the action.
• memberId — null for Connect-API-triggered runs (no human user attribution).

For console-triggered events:

• apiTokenId — null.
• memberId — the console user who performed the action.

Both surface in the activityLogs table and are visible in the run history view.

What’s NOT a trigger

A few things developers sometimes ask about that are not events:

• Form view / step / blur events — these are client-side analytics events that fire as DOM CustomEvents and push to dataLayer. They don’t trigger flows. See Forms → Events.
• API token creation / revocation — admin actions, no flow trigger.
• Studio / calendar / resource updates — admin config changes don’t fire automation events.
• Outbound webhook delivery — flows can deliver webhooks (via the form’s webhook URL), but there’s no separate “automations webhook” event you can subscribe to.

No externally-callable webhook step

There’s currently no automations webhook step that can be invoked by an external HTTP request. If you need to trigger custom server-side logic from a flow, the supported pattern is:

1. Use a form’s outbound webhook to deliver submission events to your endpoint.
2. Process the payload server-side.
3. Optionally call back into RocketLead via the Connect API (e.g., to update lead state).

Example: which automations run when I POST a lead via Connect?

A POST /connect/table_entries/ with leadStateId: <new-state> fires:

1. table.entry.added — runs every flow listening to that event for the bound Lead Pool.
2. table.entry.leadState.changed (from null → <new-state>) — runs every flow listening to that transition.

If you PATCH the entry to a different state later, only table.entry.leadState.changed fires (with the from/to transition in the run context).

Example: which automations run when I create a booking?

A POST /connect/calendar_bookings/ with a future startDateTime schedules three flow runs:

1. calendar.appointment.booked — runs immediately on commit.
2. calendar.appointment.hasStarted — runs at startDateTime.
3. calendar.appointment.hasEnded — runs at endDateTime.

If the booking is deleted before startDateTime, the pending hasStarted and hasEnded runs are cancelled, and calendar.appointment.deleted fires instead.

Shared appointments (several people in one slot)

In the console, a lead with several people — two siblings, say — can be booked into the same slot together. That creates one booking per person, grouped as one shared appointment, and the appointment events fire once for the group, not once per person:

• calendar.appointment.booked, hasStarted and hasEnded each run once, so a parent receives one confirmation and one reminder.
• Cancelling one person’s booking keeps the group’s pending runs alive while anyone is still booked. They are cancelled only when the last booking of the group goes.
• Use $attendees.* in these flows to name exactly the people still booked — see Technical reference → Variables.

Bookings created through the Connect API are always single bookings and fire per booking.

Related

• Automations → Technical Reference — execution model, node types, variable threading.
• Connect API → Leads — endpoints that fire table.entry.* events.
• Connect API → Bookings — endpoints that fire calendar.appointment.* events.
• Forms → Webhooks — how to receive form submissions server-side.