Module · Orientation
Your first automation
Lesson 2 of 9 · 4 min
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.