The automation ladder · The rungs

The Zapier chain with 11 steps

Find the four defects in a lead chain that grew one step at a time, trace where nine lost leads went, and decide what it becomes.

critiqueeasyExercise · 3 min · 16 of 75

On this page

The lead notification began as a three-step chain that took 15 minutes to build. Six months of ten-minute additions later, it loses leads without reporting a single error.

The situation

The agency's chain, from rung 1, now runs 11 steps for 400 leads a month:

form trigger
filter: sender not on the agency's domain
store get: last-seen time under the key seen: plus the email
filter: not seen in 24 hours
store set: last-seen time, now
CRM find by email
branch on the CRM field "Account manager": known or new
CRM update or create
model step: draft a reply
delay 5 minutes "for the CRM to sync"
chat message with the draft

The store is Storage by Zapier, whose keys hold up to 32 characters, with up to 500 keys per account (Save and retrieve data from Zap workflows using Storage by Zapier (opens in a new tab)). Last month the CRM field was renamed, and for three days about 36 known customers went to the team channel instead of to their account manager. Step 11 times out about twice a week. Ops clicks "replay entire run" each time, yet nine of those leads were found only when the prospects wrote again.

The question

Find the defects in this chain, say where the nine leads went, and decide whether it stays on rung 1.

A strong answer · Rubric · Where answers go wrong

Write your answer first, then open

A strong answer

Four defects, each a sign the chain has outgrown its rung.

The dedupe marks a lead seen before it is handled. Step 5 records the email before steps 6 to 11 run. When step 11 times out and ops replays the entire run, step 4 sees the email from minutes ago and stops the replay as a duplicate. The history shows a filtered run, not a failure, and that is where the nine leads went. A dedupe key is written after the work succeeds, never before.

State in a store that cannot hold it. seen: plus an email passes 32 characters for many addresses, and 400 new emails a month fill 500 keys in about five weeks. The CRM row is the dedupe already: find-or-create by email is idempotent and needs no store.

A branch on a field nobody owns. Step 7 reads a CRM field by name, so a rename misrouted 36 leads for three days with no error, and nothing ran saved leads through the edited chain before it went live.

A delay used as synchronisation. Five minutes "for the sync" is a race that fails silently when the sync takes six, and it spends the whole five-minute response target waiting.

Decision: not on rung 1. Keep a three-step notification if the team wants one, and move the rest to the nine-node router on rung 2: the CRM lookup carries the dedupe, an error output replaces replay by hand, and the committed JSON shows the next rename as a diff. About 12 hours, $1,200, against last month's 36 misrouted and 9 lost leads.

Rubric

finds that the dedupe key is written before the work succeeds, and ties it to the replays that never arrived
uses the store's documented limits and moves the dedupe onto an idempotent find-or-create on the CRM row
identifies the branch on a renamed field and the missing test before a change
calls the delay a race, not a fix
decides to leave rung 1, says what goes where, and prices the move

Where answers go wrong

"Add an error route to step 11 and keep the chain." It catches the next timeout and leaves the dedupe marking leads seen before they are handled, the store filling up, and the branch reading a field anyone can rename.

"Replace it with an agent that handles leads end to end." Nothing here needs the model to choose the next step. Module 0 priced that choice at 14 times the tokens, with a test that can no longer assert the path.

"Raise the delay to 10 minutes." It doubles the wait against a five-minute target and still races the sync.