Skip to content
RocketLead Developers

Variable placeholders — the silent-fail caveat

Variables in automation nodes use {{...}} syntax. Today there’s no validation that a variable path actually exists in the trigger’s data shape — a typo renders as empty in the output, with no error and no warning.

This is the single most common source of “the email went out but firstName was blank” debugging sessions.

How variable paths work

Section titled “How variable paths work”

A variable path is a dotted reference to data from upstream nodes:

{{<triggerNodeId>.tableEntry.data.firstName}}

That reads tableEntry.data.firstName from the trigger node’s output. If the field exists, the value is substituted at run time. If it doesn’t exist, the substitution renders empty — no error.

How to verify a path is valid

Section titled “How to verify a path is valid”

Two techniques:

1. Hover the variable chip

Section titled “1. Hover the variable chip”

In the node editor, every inserted variable renders as a colored chip. Hover over it: the editor shows the full path and resolves a sample value from the most recent trigger event (or a placeholder if no event has fired yet).

A chip that resolves to grey/blank on hover is a chip whose path doesn’t match any real field. That’s your typo.

2. Send a test trigger

Section titled “2. Send a test trigger”

For each new flow:

  1. Publish the flow.
  2. Create a real test lead with all the fields you expect populated.
  3. Trigger the flow (e.g. by booking a test appointment).
  4. Inspect the resulting email / SMS / HTTP request payload.
  5. Anything blank that shouldn’t be blank is a path that needs fixing.

This is the only fully reliable verification today.

Where typos creep in

Section titled “Where typos creep in”

The most common typo sources:

  • Custom Fields: tableEntry.data.email instead of tableEntry.customFieldData.<uuid>. The variable picker inserts the correct path; if you type it by hand, you’ll get it wrong.
  • Renamed pool fields: a flow imported from a template references firstName, but the pool actually exposes vorname. The path is syntactically valid, semantically wrong — silent fail.
  • Stale references: a Custom Field deletion + recreation gives the new field a different UUID. The flow’s reference still uses the old UUID — silent fail.
  • Trigger-source mismatch: the Customer source picker is set to the wrong pool, so the available paths don’t match the actual lead’s pool.

What proper validation would look like

Section titled “What proper validation would look like”

A future change will introduce plausibility-check warnings:

  • Yellow warning when a node references a path that doesn’t exist in the trigger’s documented output schema.
  • Red error when a node references a path that’s actively wrong (e.g. a deleted custom field UUID).
  • Optional strict mode — refuse to publish a flow with any path warnings.

Until that ships, hover-verify and test-trigger every flow before publishing.

Custom Field UUID gotcha

Section titled “Custom Field UUID gotcha”

The customFieldData.<uuid> path uses the UUID of the Custom Field, not the field’s name. The UUID is invisible in the editor; the variable picker inserts it correctly. You’ll see something like:

{{<triggerNodeId>.tableEntry.customFieldData.f3a8c2b1-...-...}}

Don’t try to “clean up” that UUID into something readable — the engine looks up the field by UUID at run time. Replacing it with a name silently breaks the variable.

See Custom Field variables for the full path conventions.

What’s next

Section titled “What’s next”