Module · The Builder
Configuring workflow details
Lesson 9 of 9 · 6 min
Everything so far has been inside a workflow. A workflow also has settings of its own: what it is called, what it looks like in a list, and what it claims to do.
This feels like housekeeping and it is not. You are going to have thirty of these. Some will have been built by somebody who has left. One of them will be doing something surprising at three in the morning, and the person trying to work out which one will be reading names in a list.
The settings, in two groups
| Group | What it is for |
|---|---|
| Day to day | |
| Only when you publish |
Day to day
- What it is for
Only when you publish
- What it is for
Almost every workflow only needs the first group, and almost every workflow is missing it. The second group is real work and you should not do it for something only you will ever open.
Naming, properly
A good workflow name answers two questions without being opened: what starts it, and what it does.
- Weak:
DB trigger test— which is what it will be called forever if you do not change it now. - Weak:
Lead automation— you will have four of those. - Good:
New contact → follow-up task— trigger on the left, outcome on the right. Findable, and it survives somebody else reading it. - Good:
Deal stage change → notify owner— same shape.
The icon and colour do more than they look like they do. When you have thirty workflows, colour by purpose — one colour for customer-facing, one for internal, one for anything that spends money — turns a list into something you can scan.
Write the description for the person who has to switch it off. One sentence: what it does, and to whom. “Emails the deal owner whenever a deal changes stage” is enough for somebody to decide, at speed, whether this is the workflow causing the problem. That is the moment this field earns its keep, and it is not a moment you will be present for.
A last word on the whole thing
You have now been through every node in this product, and one theme has run under all of it. It is worth saying plainly, at the end, rather than leaving it as a pattern you might have noticed.
Almost nothing in automation fails loudly. A campaign sends to nobody and reports success. A speech node produces no audio and returns green. A search quietly answers a shorter question than you asked. A reply goes out with a placeholder where a customer's name should be. A workflow that was never activated accepts every webhook and runs nothing at all.
Every one of those is a completed run with no failed nodes. Which means the single habit that separates automations that work from automations that appear to work is small and unglamorous:
Read the output, not the status. Every time, on the first run, and again the first time it meets real data. Everything else in this course is detail around that.
Try it
- Open every workflow you have built so far and rename them properly. It takes five minutes and it is the highest-value five minutes in this lesson.
- Give each a one-line description written for somebody deciding whether to turn it off.
- Pick a colour convention — customer-facing, internal, spends money — and apply it.
- Then open the oldest one and see whether you can tell what it does from the list alone. If not, the name is still wrong.
That is the end of the course. You have every node, the logic to join them, the agents that decide, and the tools to find out why a run did something unexpected. The rest is the thing you actually wanted to automate.