Passing data with variables
One node reaching back for another node's value. It is the whole mechanism, it is three words long, and almost every workflow that misbehaves misbehaves here.
In the last lesson the task was named after the lead, and you were told to notice it without being told how it worked. This is how it works.
Every node, when it runs, leaves its results behind under a short name. Any node after it can reach back and take a value. That is the whole idea — and everything else in this course is nodes doing interesting things with values they got this way.
Reading a reference
A reference has three parts and you read it left to right:
| Part | What it picks |
|---|---|
crmmanager_1 | |
entity | |
id |
crmmanager_1
- What it picks
entity
- What it picks
id
- What it picks
Written together: {{crmmanager_1.entity.id}}. Arrays work the same way with a number — {{crmmanager_1.results[0].name}} is the first result's name. That is as complicated as it gets.
A database trigger gives you two versions of the record. new_data is how it is now and old_data is how it was. That is how you tell what actually changed, and it is why a “when the stage changes” workflow can name both the old stage and the new one.
The rule that catches everyone
A node can only see the nodes wired directly into it. Not everything that ran. If your workflow is trigger → lookup → email, the email cannot read the trigger — the lookup is in between. The value is visibly there in the execution log, and the reference still will not resolve.
Two ways round it, and you will use both:
- Wire a second connection. A node can have more than one thing feeding into it. Draw a line from the trigger to the email as well, and both are readable.
- Carry it forward. Have a node in the middle pass the value along, or store it in a workflow variable that any node can read.
What a template can and cannot do
A field with a reference in it is a template, and templates substitute values. That is all they do.
| This works | This does not |
|---|---|
Hi {{trigger_1.new_data.first_name}} | |
{{crmmanager_1.results[0].name}} | |
{{crmmanager_1.total}} deals found |
Hi {{trigger_1.new_data.first_name}}
- This does not
{{crmmanager_1.results[0].name}}
- This does not
{{crmmanager_1.total}} deals found
- This does not
Decisions are nodes, not text. If a reply should differ depending on a value, that is a Condition node with two branches, each ending in its own message. It is more boxes and it is visible on the canvas, which is the point — a rule you can see beats a rule buried in a sentence. You will meet the Condition node properly in the Logic path.
What breaks
A wrong reference does not fail — it prints itself. Misspell the field and the workflow does not stop. The text <crmmanager_1.frist_name not found> appears wherever the value should have been, and everything downstream carries on with it. The run is green.
That single behaviour is behind more confused hours than anything else in this product. Two habits fix it: check field names against the node that produces them rather than against what they ought to be called, and read the first output your workflow produces rather than its status.
Field names come from your CRM, exactly as it spells them. first_name and not firstname or First Name. When you are unsure, run the workflow once and read what the producing node actually emitted — that list is the truth, and every node lesson in this course prints it.
An empty value and a missing one look different. A contact with no phone number gives you an empty string — the reference resolved, there was just nothing there. A misspelled field gives you angle brackets. Telling those apart in an output tells you whether your problem is data or a typo.
Try it
- Take the workflow from the last lesson and add the lead's email to the task description with a second reference.
- Now misspell it deliberately and create a contact. Read the task that appears — the angle brackets are the thing to recognise on sight.
- Fix it, then create a contact with the field genuinely blank. Compare the two results. One is a typo, the other is data.
- Add a third node after the task and try to reference the trigger from it. It will not resolve — that is the direct-connection rule, met once, properly.
- Then wire the trigger into that third node as well and watch the same reference start working.
Next: Configuring nodes right — the three things almost every node needs, and how the builder tells you which one you have missed.
Related lessons
Base rates — what a piece of evidence is actually worth
A face-recognition system that is 99.9% accurate and almost entirely wrong, and a number that sent an innocent woman to prison. Both are the same arithmetic, and it is the arithmetic that decides what any piece of evidence is worth.
ReadConfirmation and survivorship — what you never looked for
Two questions about evidence you did not go looking for. One is a rule you have to discover, and one is a pattern in five famous people — and in both, the thing that would have told you the truth is the thing nobody checks.
ReadLoss aversion, sunk cost and regression — what it costs you
Four questions you answer about yourself rather than about a scenario, and your own answers are the finding. Then the pattern that makes praise look useless and criticism look like it works, whatever you actually do.
Read