Your first automation
Two nodes, and an email that nobody sent. Read it once here and the rest of the course is detail.
You are not building yet. This lesson is one automation, in full, so that every word in the rest of the course has something concrete to attach to.
The problem it solves is small and universal. A deal moves to a new stage. The person who owns it does not find out until the weekly meeting, or until the customer asks them something they should already know.
The whole thing
A deal changes, an email goes out
Two nodes. This is a real workflow, not a diagram.
Read it left to right and there are only two ideas in it.
- The first node is watching. It is set to notice updates to deals. It does nothing until one happens — no schedule, no polling, no anybody. When somebody drags a deal into a new column, this fires.
- The second node acts. It sends an email. Who it goes to, what the subject says and what the body contains are all filled in from the deal that just changed.
The part that makes it work
Look at the email's fields. None of them contain an address or a deal name. They contain references like {{universaldatabasetrigger_1.new_data.owner_email}} — instructions to go and get a value from the record that started the run.
| What it says | What it means |
|---|---|
universaldatabasetrigger_1 | |
new_data | |
owner_email |
universaldatabasetrigger_1
- What it means
new_data
- What it means
owner_email
- What it means
That is the whole mechanism, and it is the one you will use in every workflow you ever build. One node produces something; a later node reaches back for it by name. There is an entire lesson on this later, but you have now seen it, which is most of the work.
What is worth noticing
Nobody is on a schedule. This workflow is not checking every five minutes to see whether a deal moved. It is told. The difference matters for speed and for cost, and it is the difference between the two kinds of trigger you will meet later.
The email is written once and works for every deal. There is no version of this for large deals or for a particular customer. One template, filled in differently each time — which is why an automation that takes ten minutes to build can replace something that happens forty times a week.
It is two nodes. The impressive builds at the end of this course are the same idea with more boxes. A thirteen-node workflow later in the course is not thirteen times harder; it is this, five times, joined by a decision.
And the thing to start being suspicious about now. If the field name were wrong — owner instead of owner_email — this workflow would not fail. It would run, report success, and send an email to nobody. Almost everything that goes wrong in automation looks like this, and the course spends a lot of time on it.
Before the next lesson
- Look at your own CRM and find something that changes often — a stage, a status, an owner.
- Ask who currently finds out when it changes, and how long that takes.
- Write the sentence: “when X changes, tell Y.” If you can write it, it is a two-node workflow.
Next: Your first AI agent — the same three parts, where the middle one holds a conversation.
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