Course resource

Router Logic Blueprint

Branching, filtering and looping in an automation — the patterns, and the mistakes that cost money.

The four control structures

Every branching workflow is built from these.

Filter — stop unless a condition is true.

Trigger: new email
Filter: label = "support" AND sender not in [internal domains]
→ continue only if both true

The single most important structure, and the most commonly omitted. A workflow without a filter runs on everything and you find out on the bill.

Router — send down one of several paths.

Trigger: new form submission
Router:
  Route A: urgency >= 8        → page the on-call person
  Route B: category = billing  → billing queue
  Route C: category = technical→ tech queue
  Route D: fallback            → general queue + notify human

Always have a fallback route. Without one, anything that matches no branch vanishes silently — the hardest class of bug to notice.

Iterator — process a collection one item at a time.

Input: an email with 5 attachments
Iterator: for each attachment → extract text → save row

Aggregator — collapse many items back into one.

After the iterator: aggregate the 5 extracted texts
→ one AI summary of all five
→ one Slack message

Iterator and aggregator come as a pair. Iterating without aggregating gives you five separate notifications where you wanted one.

Choosing

Situation Structure
Should this run at all? Filter
Different handling for different types Router
Several items arrived together Iterator
Need one output from many items Iterator + aggregator
Same step repeated until a condition Loop — use sparingly, always with a cap

Where AI goes

AI is the step that makes the judgement a router acts on. Keep it separate from the routing itself.

Trigger → AI classifies → Router branches on the classification → action

Not:

Trigger → AI decides what to do and does it

The first is debuggable: you can see what it classified and why it routed that way. The second is a black box, and when it misbehaves you cannot tell whether the judgement or the action was wrong.

Constrain the classification output:

Classify this message into exactly one of: billing, technical, sales, other.
Respond with only the single word. No explanation, no punctuation.
If genuinely ambiguous, respond: other

Then set the temperature to 0–0.2. A classification step at 0.8 will route the same input differently on different runs, and you will spend an hour debugging a workflow that is working exactly as configured.

Loop safety

Loops are where automation bills go wrong.

The mistakes that recur

No filter. Runs on every item instead of the relevant ones. The most expensive mistake.

No fallback route. Unmatched items disappear. Nobody notices for weeks.

Routing on unvalidated AI output. The AI returned "Billing." with a full stop, your router matched on "billing", and everything fell to the fallback. Normalise before comparing: trim, lowercase, strip punctuation.

Testing only the happy path. Every branch needs a test, including the fallback.

Iterating without aggregating. Twenty notifications instead of one.

High temperature on a judgement step. Non-deterministic routing.

No logging. Something misrouted three days ago and there is no record of what the AI returned.

Testing every path

Do not launch until each row is filled.

Path Test input Expected Actual Pass
Route A
Route B
Route C
Fallback deliberately unmatched input
Filter rejects input that should not run nothing happens
AI returns junk garbled input falls to fallback, alerts

The last two rows are the ones people skip and the ones that break in production.

Before it goes live

Back to dashboard