Lab: Your first workflow
Build, test, and turn on Riley's email→ticket workflow end to end — trigger, filter, formatters, two actions, and a five-email test suite.
Build day. You'll construct the full email→ticket workflow — the automate-now #1 from Riley's map, and the pattern behind half the office automations ever built. Use your own accounts (a personal email + any spreadsheet + optionally a chat app). Every instruction below is platform-neutral; part of the lab is finding each construct in your tool, which is a skill, not an inconvenience.
The target
TRIGGER new email in [your test mailbox]
FILTER subject does NOT contain 'unsubscribe'
AND from is NOT [your own domain]
FORMAT extract order number from subject: pattern HL-\d+
(fallback if absent: 'none')
FORMAT trim body to 500 chars
ACTION add row to sheet 'Tickets':
timestamp | from | subject | order# | body-trimmed | status='new'
ACTION (optional) post to chat: 'New ticket from {from}: {subject}'That own-domain filter will eat your test emails. Send your tests from a second free email account, or add the own-domain condition only AFTER testing — otherwise your own tests get filtered and the workflow looks dead. The most common 'it's broken' report in this lab isn't broken at all.
The extraction pattern, literally: HL-\d+ — the letters HL-, then one or more digits. This is called a pattern (regex); copy it exactly — Zapier's Formatter → Extract Pattern and the n8n/Make equivalents all accept it.
- 1Prepare the landing zone: a 'Tickets' sheet with the six column headers. Output first, then the workflow that fills it — always design backward from the output.
- 2Send yourself a sample record ('Order HL-1042 arrived damaged') before building, so the trigger has a real field bundle to map against.
- 3Build in order: trigger → filter → two formatter steps → add-row action. Rename every step as you go. Map fields by picking from the sample record.
- 4Test with the five-email suite: (1) normal with order number, (2) no order number — fallback should say 'none', not crash, (3) empty subject — your empty-field default earns its keep, (4) an 'unsubscribe' newsletter — must NOT create a row, (5) forwarded mess with the order number buried in the body — expected to fail at extraction; note the failure, we fix it with AI in Module 3.
- 5Turn it on and log the win: note your build time and the weekly minutes it retires. That ratio — an evening against 3+ hours a week, forever — is the argument for this entire discipline. You'll cite it when someone asks why ops suddenly has opinions about software.
Every platform shows the run history: each run, each step, data in, data out. Debugging is reading it: find the first step whose output looks wrong, look at what went in, fix the mapping or filter, re-test. Two broken runs are part of the lab, not a deviation from it — nobody's first workflow works first try, and run-history literacy is the actual skill being installed.
Three workflow specs to critique and repair on paper: a filter placed after the send step (you know this one), a mapping that assumes every field is always filled, and a schedule trigger reading 'all rows' instead of 'new rows since last run' (the classic double-processing bug). Reading workflows for failure — before they run — is the reviewer skill that makes you the team's automation person.