Skip to content
RocketLead Developers

The "Customer source" picker on triggers

Some triggers — notably “new appointment booked” — fire on a Calendar event, but the data they offer downstream includes the lead (the appointment’s tableEntry). The lead’s available fields depend on which Lead Pool it lives in.

To make the variable picker show the correct fields, you have to tell the trigger which pool the lead comes from. This is the Customer source picker.

Where to find it

Section titled “Where to find it”

On the trigger node’s edit panel. After picking the calendar(s) you want the trigger to listen to, there’s a separate Lead source / Customer source dropdown. Pick the Lead Pool(s) the leads come from.

What it changes

Section titled “What it changes”

Without it: the variable panel shows generic tableEntry.data and tableEntry.customFieldData with no specific field names. You can still build the flow, but you have to type field paths by hand.

With it: the variable panel populates with the actual field names from the selected pool(s). The variable picker offers each field as a clickable chip.

Why it’s not automatic

Section titled “Why it’s not automatic”

In principle, RocketLead could derive the source pool dynamically from the calendar (calendars and pools are both linked to Standorte). In practice it doesn’t, because:

  1. A calendar can belong to multiple Standorte (rare but supported).
  2. An appointment booking is sometimes for a lead in a different pool than the “default” linked one.

So the picker exists to be explicit. Long term this should be automatic — until then, pick the pool.

In multi-source orgs

Section titled “In multi-source orgs”

If a trigger should fire for multiple calendars across multiple pools, the Customer source picker accepts multiple pools. The variable panel then unions the field sets — fields that exist in all pools show up cleanly; fields that exist in only some pools show as “may be undefined”.

For best practical results, make sure all pools have the same field keys (firstName, lastName, email, phone). This is the “stable key” convention from Ingress webhook bootstrap — it pays off here.

Symptoms when this is wrong

Section titled “Symptoms when this is wrong”

If the variable picker is missing the lead fields you expect, you skipped the Customer source picker (or selected the wrong pool). The fix is to set it on the trigger, then re-click any downstream nodes — the variable list re-populates as soon as the trigger output schema is known.

A common downstream symptom is “the email goes out with empty firstName” — the path in the email body references a field that doesn’t exist on the snapshotted lead because the picker pointed at a pool that uses different keys.

What’s next

Section titled “What’s next”