Configuring nodes right
A node on the canvas does nothing until it is configured. Three things cover almost all of it — and the builder will tell you which one you have missed, if you let it.
Dragging a node out is the easy half. Every node arrives with sensible-looking defaults and does nothing useful until you have made three decisions about it.
The three things
| Decision | What it means |
|---|---|
| The operation | |
| The integration | |
| The variables |
The operation
- What it means
The integration
- What it means
The variables
- What it means
Get the operation first, always. The panel reshapes around it. Filling in fields and then changing the operation means filling in a different set of fields, and half of what you typed is now irrelevant and still saved.
The builder checks your work — up to a point
Nodes are validated as you go, and a workflow can tell you what is not yet ready. There are two different states worth telling apart, because they mean different things:
- Something is wrong. A required field is empty, or a value is not one of the allowed ones. This blocks the workflow and the message names the node and the field.
- Something needs a human. A node needs an integration chosen, and no amount of configuration text can supply it — somebody has to pick an account. The workflow is structurally fine and still cannot run.
There is a third message worth recognising: a configuration key that is not in the node's schema. It means you set a field the node does not have — usually a plausible guess at a name. It is a genuinely useful error, because the alternative is a value that is silently ignored. When it appears, look up the real field name rather than removing the line.
What the checks cannot tell you
This is the important half of the lesson, and it is why the rest of this course reads the way it does.
A node can be perfectly configured and still do nothing. Every field valid, every requirement met, and the behaviour wrong — because a default was not what you assumed. A speech node whose voice provider is set to “none” produces no audio and reports success. A search with no filter returns everything. A send with an empty list sends nothing and finishes happily.
So configuration checks are a floor, not a ceiling. They tell you the workflow is well-formed. Whether it does what you meant is answered by running it and reading the output — which is what the debugging lessons are for, and why nearly every node lesson in this course ends with what breaks rather than what works.
A working habit
- Choose the operation, then read the whole panel. Including the fields you were not going to touch. Defaults are decisions somebody else made for you.
- Set the integration explicitly when it matters. Which mailbox an email leaves from is not a detail to a customer.
- Type the values first, then replace them with variables. Getting a node working with a hard-coded email address and then swapping in a reference separates two problems that are much worse together.
- Save, then run the single node. One node's output tells you more than a whole workflow's status, and it takes two seconds.
- Read what it produced, not whether it ran. Every time.
What breaks
Editing a field and running without saving tests the old value. The buttons sit next to each other for a reason and everybody does this once. If a change appears to have had no effect, this is the first thing to check.
A default integration is fine until there are two. A workflow built when the organisation had one mailbox keeps working, and starts sending from the wrong address the day somebody connects a second. Nothing about the workflow changed.
Values left over from a previous operation are still saved. Configure a node one way, change the operation, and the earlier fields remain in the definition even though the panel no longer shows them. Harmless most of the time, confusing when you read the saved workflow later and find fields that make no sense.
Try it
- Take a node with several operations and switch between two of them, watching the panel change. That reshaping is the thing to expect.
- Leave a required field empty and ask the builder to check the workflow. Read how it names the node and the field.
- Now fill everything in correctly, but set one value to something valid and wrong — a limit of 1, a filter that matches nothing. The check passes. Run it and read the output.
- Change a field, do not save, and run the node. Then save and run it again. Feel the difference once so you recognise it later.
Next: Variables in action — running the workflow and opening a node to see what really arrived, which is the skill everything above depends on.
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