Module · How a workflow is built
Variables: how one node uses another's output
Lesson 11 of 40 · 7 min
Every node, when it runs, leaves its results behind under its alias. Any node after it can reach back and take a value. That is the entire mechanism, and every interesting thing in your org is a node doing something with a value it got this way.
A reference has three parts
| Part | What it picks |
|---|---|
scored_enquiry | Which node. Its alias — the short name under the tile. |
new_data | Which part of that node's answer. A node usually produces more than one thing. |
value | Which field of that. Keep going as deep as the data goes. |
scored_enquiry
- What it picks
- Which node. Its alias — the short name under the tile.
new_data
- What it picks
- Which part of that node's answer. A node usually produces more than one thing.
value
- What it picks
- Which field of that. Keep going as deep as the data goes.
Written together: {{scored_enquiry.new_data.value}}. That is as complicated as it gets — and it is read left to right, like a postal address, narrowing at every step.
Where an agent's knowledge actually comes from
Open 2.3 · Mark every lead hot, warm or cold — and say why and click the agent. Its prompt has a section that is nothing but references:
## Available Context
- Enquiry: {{scored_enquiry.new_data.name}}
- Enquiry id: {{scored_enquiry.new_data.id}}
- Requirement value: {{scored_enquiry.new_data.value}}
- Source: {{scored_enquiry.new_data.source}}
- Stage: {{scored_enquiry.new_data.stage_name}}
- What we know so far: {{scored_enquiry.new_data.description}}An AI node knows nothing except what a reference hands it. There is no hidden connection to the CRM. Those six lines are the entire world this agent can see, and the quality of its scoring is decided by them before the model is ever asked anything.
The dot that catches everyone
A CRM trigger nests the changed record under new_data. It is {{scored_enquiry.new_data.value}}, never {{scored_enquiry.value}}. The second one looks more sensible and it is wrong, and it is behind more confused half-hours in this product than anything else.
The trigger hands over two versions of the record — how it is now, and how it was. That is how a workflow that fires on “the stage changed” can name both the old stage and the new one.
When a reference is wrong, nothing fails
Misspell a field and the workflow does not stop. The text of the reference is replaced by a note saying it could not be found, and everything after it carries on:
written: {{scored_enquiry.new_data.value}}
resolved: 3319683.0
mistyped: <scored_enquiry.new_data.valu not found>The run is green. The task is created. The agent answers confidently. In an ordinary node that note lands in a message a customer reads. In an Core Agent it lands inside the prompt — so the model is not stopped, it is simply told nothing, and it scores the enquiry blind.
Empty and missing look different
The other half of this, and the half that saves you an argument with a client: a reference that resolves to nothing is not the same as one that does not resolve.
| What you see in the output | What it means | What to do |
|---|---|---|
… from . | The reference worked. The field was genuinely empty on that record. | A data problem. Go and look at the record. |
… from <alias.source not found> | The reference did not work. The path is wrong. | A typo. Go and look at the node that produces it. |
… from .
- What it means
- The reference worked. The field was genuinely empty on that record.
- What to do
- A data problem. Go and look at the record.
… from <alias.source not found>
- What it means
- The reference did not work. The path is wrong.
- What to do
- A typo. Go and look at the node that produces it.
The first row is not hypothetical. On 18 August a real enquiry in this org went through 3.1 · Call every new lead back within 5 minutes and produced a task whose description reads “High-value enquiry (₹3319683.0) from .” — because that enquiry had no source recorded. Nothing failed, nothing was flagged, and the advisor got a sentence with a hole in it.
A node can only see what is wired into it
Not everything that ran — only the nodes with a line drawn directly into this one. 8.1 · Tell Meta which leads were actually good is the clean example: its last node reads only the node immediately before it.
8.1 · Tell Meta which leads were actually good
Every reference in the last node points at find_contact, which is wired straight into it. Nothing in it reaches back past that node to the trigger.
Scroll for all 3 steps →
If a value you need is two nodes back, either draw a second line to it or carry it forward. The value is visibly there in the execution log and the reference still will not resolve, which is exactly the kind of thing that costs an afternoon if nobody told you.
Change one thing
This one is live — 2.3 · Mark every lead hot, warm or cold — and say why is an active workflow — and it is additive, so it cannot break the scoring.
- Open it, click the agent, and find the
## Available Contextsection of its prompt. - Add one line:
- Deal number: {{scored_enquiry.new_data.deal_number}} - Save. Do not run anything yet.
- Read the line you just wrote and say which node it points at, which part of that node's answer, and which field. If all three are obvious, this lesson has done its job.
Leave that line in place. The next lesson fires this workflow for real and reads the prompt the agent actually received — and your line will be sitting in it with a number where the brackets were.
Try it
- Go through three workflows and, for every
{{ }}you find, name the node it points at without scrolling. - Find a reference that points at a node two boxes back, and check whether a line is drawn to it.
- Find the longest reference in the org. Read it aloud. It is still just node, part, field.
Next: Conditions and branches — what happens when a workflow has to choose.