Skip to content
RocketLead Developers

Snapshot semantics — what gets frozen vs. fetched live

When a trigger fires, the automation engine takes a snapshot of three things:

  1. The flow definition (which nodes exist, in what order, with which config).
  2. The lead (tableEntry) — every field, every value.
  3. The appointment (if the trigger references one) — full appointment record.

The snapshot is stored alongside the queued run. When the run executes — which may be immediately, or 24 hours later for a “1 day before” reminder — the engine uses the snapshotted data, not the current state of the lead or appointment.

Standort variables ($studio.*) are the exception — they’re resolved dynamically at run time, not from the snapshot.

Why snapshot most things

Section titled “Why snapshot most things”

The engine is asynchronous. A trigger fires now; the run might execute now (immediate), in five minutes (delayed), or in three weeks (a future appointment’s reminder). Between fire and execute:

  • The lead’s name might change.
  • The lead might move to a different pool.
  • A custom field used by the flow might be deleted from the pool’s schema.
  • The flow itself might be edited or unpublished.

Without snapshotting, any of those changes could leave a queued run in an unrecoverable state — a “send email” node referencing a field that no longer exists, or branching on data that has since been overwritten.

Snapshotting freezes the input. The run uses what was true when the trigger fired. If the operator wants the run to reflect later changes, they have to cancel the queued run and re-trigger it.

Practical implication: name corrections

Section titled “Practical implication: name corrections”

If you fix the spelling of a lead’s name after an appointment is booked, the reminder email that goes out the day before the appointment will use the old spelling — because the lead snapshot was taken at booking time.

There’s no perfect answer here. The trade-off was made in favor of run reliability (no “field missing” runtime errors); the cost is that late edits don’t propagate to in-flight runs.

Why Standort variables are different

Section titled “Why Standort variables are different”

The Standort ($studio.*) data — address, phone, email, website — is:

  1. Stable across the run’s lifetime in practice. A studio’s phone number rarely changes between trigger fire and reminder send.
  2. Operationally important to update late. When a studio’s phone number does change, the customer wants every email — including the ones already queued — to reflect the new number. Otherwise customers call the disconnected old number.
  3. Not customer-editable. Operators control Standort data, not end users, so the risk of late-edit corruption is lower.

For these reasons, $studio.* resolves at run time from the live Standort record. If you update a studio’s phone number today, the appointment reminder going out tomorrow uses the new number.

What’s snapshotted vs. live — at a glance

Section titled “What’s snapshotted vs. live — at a glance”
SourceSnapshot or live?
Lead field values (tableEntry.data.*, tableEntry.customFieldData.*)Snapshot
Appointment details (appointment.*)Snapshot
Flow definition (nodes, branching, email body text)Snapshot
Standort variables ($studio.phone, $studio.email, $studio.address, $studio.website, $studio.name)Live — re-resolved on every step
Global variables ($global.*)Live — re-resolved on every step from the org’s global-variables record
Lead state at run timeSnapshot (snapshotted at trigger time; later state changes don’t affect the queued run)
Custom Field UUIDs referenced in the flowSnapshot (so a deleted field doesn’t break the run, but the value referenced is the value at snapshot time)

$global works exactly like $studio for snapshot purposes — both are pulled live before each step executes. The conceptual difference: $studio reflects per-Standort data; $global reflects org-wide variables operators define centrally.

What this means for editing

Section titled “What this means for editing”
  • Editing a flow doesn’t change currently-queued runs. The next trigger event uses the latest published version; queued ones run with their snapshotted version.
  • Editing a lead doesn’t change queued reminder runs for that lead’s appointments. The reminder uses the lead state captured at booking.
  • Editing a Standort or a $global variable does affect future runs — including already-queued ones. Use this to your advantage when a phone number or a shared text fragment changes.

What’s next

Section titled “What’s next”