Filters, paths & formatting

Straight-line workflows handle one case. Real work has cases, plural: the order-issue email and the newsletter both land at support@; the urgent complaint and the routine question deserve different speeds. Two constructs handle nearly all of it:

• Filters are bouncers: a condition mid-workflow that stops the run unless it's met ('continue only if from is not on the internal-domains list', 'only if subject doesn't contain unsubscribe'). Put your filters immediately after the trigger — stop irrelevant runs before they consume steps, AI calls, or (worse) send anything. A well-filtered workflow runs less and matters more.
• Paths/branches are forks: different cases, different steps ('IF body contains an order number → ticket route; OTHERWISE → general-inbox route'). Rule of thumb: 2–3 branches is a workflow; 6+ branches is several workflows wearing one trench coat — split them by trigger filter instead, and each stays simple.

Formatter steps: the unglamorous 20%

Between trigger and output you'll constantly reshape data with small utility steps: extract the order number from the subject with a pattern (HL- followed by digits), trim the body to 500 characters, lowercase the email, split a full name, convert the date. Platforms bundle these as formatter/text/date tools — no code, pick-from-menu. A typical production workflow is one trigger, one filter, three formatters, two actions: the formatters are the work.

Readability: the maintenance insurance

1. 1Rename every step from the default to what it does: 'Extract order # from subject', not 'Formatter 2'. Future-you debugging at 5pm Friday will send thanks.
2. 2Add a description on the workflow itself: what it does, what triggers it, who owns it, last-reviewed date. Three sentences; write them while you remember.
3. 3One workflow, one job. The moment a workflow's honest description needs the word 'and also', split it. Small workflows compose (one can trigger another); big ones just break bigger.