Rung 1 — trigger-action tools (Zapier, Make)
Build a form-to-CRM-to-chat chain in 15 minutes, use its branches, error route and store, and spot the four signs a chain has outgrown the rung.
On this page
A trigger-action tool runs a chain: one event starts it, and each action receives what the steps before it produced. It is the cheapest rung to build on, and the agency's lead notification takes about 15 minutes there. It is also the rung that is easiest to stay on too long, because a chain accepts one more step at a time long after it should have become a graph.
The running example is the agency's inbound-lead workflow from scripts, workflows and agents: 400 leads a month from three sources, 10 minutes of a person's time each, $2,000 a month at the assumed $30 an hour for staff. Module 0 put the whole workflow on rung 2; this lesson builds the part rung 1 does well.
The worked chain: form, CRM row, chat message
Three steps, in the order they run:
- Trigger: a new entry on the lead form.
- Action: find the contact in the CRM by email, and create a row if there is none.
- Action: post the name, company and message to the account managers' channel, with a link to the row.
Building it means connecting three accounts, mapping fields and testing each step on one sample entry: about 15 minutes, or $25 of founder time at the assumed $100 an hour. Assume it removes 2 of the 10 minutes an account manager spends on a lead, the CRM lookup and the hand-off: 400 × 2 minutes is about 13 hours a month, or $400. Over about 22 working days that is $18 a day, so the $25 is back within two working days, a ratio no other rung matches.
What the rung gives you beyond a straight line
Both large tools on this rung offer the same five additions to a straight chain, under different names.
Branching. In Zapier, a filter stops the run when a condition fails, and Paths give each outcome its own branch (Add conditions to Zap workflows with filters (opens in a new tab), Add branching logic to Zap workflows with Paths (opens in a new tab)). In Make, a Router splits a scenario into routes, each behind its own filter, with an optional fallback route for whatever matches none (Router (opens in a new tab)). In the worked chain, a filter drops test entries from the agency's own domain, and a branch sends new contacts to the team channel and known ones to their own account manager.
An error route. A step that calls another system will fail some of the time. Zapier attaches an error path to a single step, which runs in place of the rest of the chain when that step errors (Set up custom error handling (opens in a new tab)). Make offers handlers that retry, resume with a substitute value, commit, roll back or skip (Error handlers (opens in a new tab)). On the CRM step, the route emails ops the error and the lead, so a failure reaches a person.
A delay. Zapier's delay step waits a fixed time or until a set time before the next action runs (Add delays to Zap workflows (opens in a new tab)). It suits "send the follow-up at 09:00 tomorrow", not "wait until the CRM has synced", which is a race.
Replay of a failed run. Zapier replays either the errored steps or the entire run; an entire-run replay runs every step again, including the ones that already succeeded (Replay Zap runs (opens in a new tab)). Make, once incomplete executions are turned on in a scenario's settings (they are off by default), keeps a failed run to retry or resolve by hand (Incomplete executions (opens in a new tab)). If a step fails after a step that creates a record, an entire-run replay creates the record twice. The worked chain's CRM step looks before it creates, so it survives a replay; replay is safe only for an idempotent step, as idempotency and deduplication explains.
A key–value store. Storage by Zapier saves small values that later runs can read back (Save and retrieve data from Zap workflows using Storage by Zapier (opens in a new tab)), and Make's data stores keep records across scenarios (Data stores (opens in a new tab)). A store suits a counter or the id of the last record processed. When the chain's state lives there, the chain is in trouble.
The mistake: a chain that grows one step at a time
In month one the agency's chain had the three steps above. By month three it had a filter and a branch on a CRM field. By month six it had eleven steps: a store holding a "last seen" time per email to suppress duplicates, a model step that drafted a reply, and a delay to give the CRM time to sync. Each addition took ten minutes and was reasonable on the day.
Then someone renamed a field in the CRM. The branch condition that read it stopped matching, and every known contact fell through to the fallback branch for new contacts, which posted to the team channel instead of to each customer's own account manager. Nothing reported an error, because a branch that matches nothing is not an error. It ran for three days before an account manager asked why her customers had gone quiet: 400 ÷ 30 × 3 = 40 leads, nine in ten of them known contacts at module 0's match rate, so about 36 misrouted, against a five-minute response target. The eleven-step chain exercise takes that chain apart.
The fix was not a better chain. The chain had been doing a graph's job without a graph's tools.
The ceiling, as four checks
- No typed state. Every value between steps is text in a field: "1,200" in one run, "1200" in the next. Nothing checks what a step hands the next one.
- No test that runs before a change goes live. You test a step by hand on one sample entry; nothing replays last month's 400 leads through the edited chain.
- No versioned diff. Zapier keeps earlier versions that you can restore and edit from (Restore your Zap to a prior version with version rollback (opens in a new tab)), which undoes a mistake once noticed. Nobody reviews a diff before a change is published.
- No run on your own machine. The chain lives in the vendor's editor, so it cannot run against a saved fixture on a laptop, or in a pipeline that blocks a bad change.
The signs show on the chain itself before any of the four bites: a store used as state, a second branch, a delay used to wait for another system, or a model step whose output decides a branch. One sign is a warning; two mean the task belongs on rung 2, the visual orchestrator, where the same chain becomes nine nodes in a file that a repository can diff.
In practice
Say this to the team: rung 1 is for chains of about five steps that hold no state and have no model output deciding a branch. Anything else starts on rung 2, even when the editor would accept it. Every step that calls another system gets an error route to a named person; a shared inbox counts as nobody.
The mistake that costs money is letting a chain grow one ten-minute step at a time past the ceiling. No single step looks like a decision, so nobody prices the move. The 36 leads that went to the wrong place for three days were the price of a branch nobody re-tested.
Check yourself
1. Every new hire needs accounts in four tools and a welcome message: about 2 a month, 30 minutes each by hand, no judgment. Which rung, and what would rung 2 cost?
Rung 1: five actions, no state, no branch. By hand it costs 2 × 30 minutes = 1 hour a month, $30 at $30 an hour. A chain of about 30 minutes, $50 of founder time, pays back in under two months. Assume rung 2 takes 4 hours, $400: 13 months, past the 12-month life module 0 gives every automation, for capabilities the task never uses.
2. A chain creates an invoice in the accounting system, then emails it. The email step fails on 5% of the 40 invoices a week, and ops clicks "replay entire run" on each. How many duplicate invoices a year, and what do you change?
40 × 5% = 2 failed runs a week, and each entire-run replay creates the invoice again: about 100 duplicate invoices a year, some of which reach a client. Replay only the errored step, and make the invoice step look for an invoice with the same timesheet id before creating one, so no replay can duplicate it.
3. The team wants a model step that labels each lead as sales, partner or not a lead, and a branch on the label, inside the chain. Do you allow it?
No. A model output that decides a branch, with no test that runs before the prompt changes, is the last sign of the ceiling: a reworded prompt re-routes leads with no error anywhere. Keep the three-step notification on rung 1 and build the classification as one node in the rung 2 graph, where the prompt lives in the repository and a change is a diff someone reviews.