Skip to content

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.

EventWhen it fires
table.entry.addedA new lead entry is created in any Lead Pool
table.entry.leadState.changedAn entry’s leadStateId changes (including the initial null → state transition on creation)
calendar.appointment.bookedA booking is created
calendar.appointment.hasStartedAt the booking’s startDateTime
calendar.appointment.hasEndedAt the booking’s endDateTime
calendar.appointment.deletedA booking is deleted
EventForm widgetIngress webhookConnect APIConsole 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)

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.
  • memberIdnull for Connect-API-triggered runs (no human user attribution).

For console-triggered events:

  • apiTokenIdnull.
  • memberId — the console user who performed the action.

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

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.

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?

Section titled “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?

Section titled “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.