Module · Full builds
Google Calendar to tasks
Lesson 11 of 11 · 4 min
Every lesson until now has been a recipe — a node, its fields, a small workflow that demonstrates it. The two builds before this one were tight: four nodes, six nodes, walked carefully.
This one is not. It is a workflow somebody would build because they had a real problem, and it looks like it: one trigger, a classifier, a router, and five branches that do completely different things. There is no walkthrough. Look at the shape, look at four pieces of it, and notice that you already know what every box does.
The build
One trigger, five branches, thirteen nodes
Read it as a spine and five limbs rather than as thirteen nodes.
Scroll for all 13 steps →
The spine is four nodes: read the calendar, work out what kind of day it is, route on that, and then five branches each handle their case. Everything interesting happens because of the second node.
Four pieces worth looking at
The classifier is a Custom Function, and it exists to give the router one field. You could branch on five separate conditions reading five different calendar fields. Instead a small piece of Python reduces the whole event to a single word — notes_attached, external_meeting, cancelled — and the router switches on that. The workflow is far easier to read, and when routing goes wrong there is exactly one place to look.
The router is a Multi-Condition, and its paths are evaluated in priority order with a default. First match wins. The default path is not decoration — it is the branch for the day when nothing is in the calendar, and a router without one silently drops those runs.
The headline branch reads a document, hands it to a model, and bulk-creates tasks. Google Docs pulls the meeting notes, an LLM Integration in JSON mode extracts agreed actions into a list, and a single CRM Manager in batch mode creates all of them. That is three nodes doing something that would otherwise be somebody's Monday morning.
One branch waits two days before it does anything. A Delay between the thank-you email and the follow-up task. Nothing is running during those two days — that is the whole point of the node — and the workflow simply resumes.
The four decisions inside those pieces
| Choice | Why it is that |
|---|---|
- Why it is that
- Why it is that
- Why it is that
- Why it is that
What this is really showing you
Not this build. You will never need this exact workflow. What it shows is that the difference between the four-node example and the thirteen-node one is not skill — it is that somebody kept adding branches as they met new cases.
- The spine stays small. Trigger, get the data, classify, route. Almost every large workflow in the wild has this shape, and the ones that do not are the ones nobody can maintain.
- Branches are independent. Each is a small workflow. You can add a sixth without understanding the other five, and you can break one without breaking the rest.
- Classify once, branch on the result. Every large workflow that becomes unreadable does so because the same decision is re-derived in four different Conditions.
Large workflows fail in the ways this course has been describing, only harder to spot. Five branches means five chances for a completed run that did nothing — a batch create with an empty list, a branch that never fires because the classifier returns a word the router does not know, a delay that resumes into a node whose data has moved on. Everything in the debugging lessons applies more here, not less. The output_path on the router is the first field to read, every time.
Build something
- Take a real problem you have and write down the spine only: what starts it, what it needs to know, and what the one classifying question is.
- Build the spine and one branch. Run it. Resist adding the second branch until the first is genuinely working.
- Add branches one at a time, and give the router a default from the start.
- When a branch grows past about six nodes, ask whether it wants to be its own workflow called from this one.
- Then leave it running for a week and read the executions — not the failures, the successes. That is where you will find what you got wrong.
That is the end of the builds. What remains is Get Started — the orientation lessons, which are last on purpose: they are far easier to read once you know what all the words mean.