Loading tutorials…
Loading tutorials…
One trigger, three or four actions. Easy to draw on a whiteboard, easy to break in production. This walks through chaining, naming, and the error scenarios that hit you on day 30, not day 1.
Who this is forOperators who already shipped one Zap and now need to chain 2-5 actions together. If your single-Zap count is climbing past 10 and each one is fragile, the technique here scales better than another single-step.
What you'll need
Step 1
On paper or in a notes file, write each step: trigger → action 1 → action 2 → ... Include the specific app, event, and the 2-3 fields each step needs.
Multi-step Zaps fail when the builder loses track of what data is available at each step. The fix is a 5-minute diagram.
Write each step on its own line: "Step 1 (Trigger): Typeform — New Entry. Outputs: email, company, plan_tier."
"Step 2 (Action): HubSpot — Find or Create Contact. Inputs: email (from Step 1). Outputs: contact_id."
"Step 3 (Action): Slack — Send Channel Message. Inputs: company, plan_tier (from Step 1), contact_id (from Step 2)."
Now you know exactly which earlier step each field comes from. No guessing in the data picker.
If any step needs data not in the diagram, the chain is incomplete. Pause and fix the diagram first.
Step 2
Don't try to be clever. Build trigger + action 1, test it end-to-end, name the Zap, then add action 2.
In Zapier → Zaps → + Create → Zap, set up the trigger as you would for a single-step Zap.
Pull live sample data and test the trigger. Confirm the sample has every field your downstream steps need.
Add Action 1. Configure it fully. Click "Test action" and verify the destination app received a real record.
Rename the Zap to match the diagram: "Typeform → HubSpot + Slack: lead intake."
Now and only now, add Action 2. Adding 3-4 actions before testing any of them is the most expensive shortcut in Zapier.
Step 3
For action 2 onward: add → configure → test → verify in destination → only then add action 3.
Click the "+" between the last action and the editor footer. Choose the next app and event.
Configure all required fields. When mapping, you now see two sources in the data picker: trigger output AND action 1 output. Pick from whichever step actually has the field you need.
Critical: a downstream step often needs an ID returned by an upstream step (e.g., HubSpot contact_id). Use the upstream step output, not the original trigger output.
Click "Test action." Verify the destination app received the correct record. Verify the fields downstream of upstream IDs are linked correctly (open the new HubSpot contact, click the linked deal, confirm it actually links).
Only after this passes, add the next action.
Step 4
Rename every action card from "Action: Slack" to "3. Slack — notify SDR channel." Future-you will recognize them in Zap History.
Hover the action card → click the title → rename.
Convention: "[step number]. [app] — [what it does in one phrase]." Example: "2. HubSpot — Find or Create Contact" / "3. Slack — Notify #leads channel" / "4. Filter — only paid plans."
In Zap History, errors show the failing step name. "Action: HubSpot" tells you nothing. "2. HubSpot — Find or Create Contact" tells you everything.
This becomes critical once you have a Zap with 6+ steps and an error fires in step 4.
Step 5
What happens if step 3 fails? Does the Zap halt entirely, or does step 4 still run? Default behavior is halt — usually what you want, but you should verify.
Zapier default: if any action step fails, the whole Zap halts for that run. No subsequent steps execute.
For most lead-intake Zaps this is correct. You do not want to send a "welcome" email if the contact creation failed.
For some workflows (e.g., logging + non-critical notifications), you want some steps to be optional. Today the cleanest way is to wrap the optional action in a Path with a forgiving filter, or to use Code by Zapier to handle the call with try/catch.
Decide per Zap: which failures are blocking, which are best-effort? Document this in the Zap description field.
Set up error notifications: Zap → Settings → "Send email if Zap stops working" → ON. For multi-step Zaps, also consider piping errors to Slack via an "error Zap" so the team sees them.
Step 6
Before turning on, generate a real trigger event from the source app. Verify every action step ran and every destination record looks correct.
Generate a real trigger event in the source app — submit a real form, add a real row, etc.
Open the Zap → History tab. Find the run. Click in.
Expand each step. Verify the input data and output data match what you expect.
In each destination app, find the created record. Verify field-by-field.
If anything is wrong, fix in the editor and run another end-to-end test. Do not assume one-step fixes do not break two-step downstream effects.
Step 7
Click Publish. For the first week, check Zap History daily. Multi-step Zaps fail in subtler ways than single-step Zaps.
Click Publish. The Zap is live.
Daily for 7 days: open Zap → History. Sort by status. Confirm zero "Error" or "Halted" runs.
If you see errors, click in to see which step failed and why. Common causes: empty optional fields, rate limits on the destination app, a missing record the action assumed would exist.
After 7 clean days, drop to weekly monitoring. Most Zaps that survive 7 days survive 7 months — issues usually surface from data-shape changes (e.g., the source form added a new field).
Common mistakes
Building all steps before testing any
What goes wrong: You configure a 5-step chain, click test on step 5, get an error, and have no idea which step is wrong. Debugging takes 2-3 hours per Zap instead of 20 minutes.
How to avoid: Build one step at a time. Test after each. Add the next only when the current step passes its test.
Mapping the wrong upstream step
What goes wrong: Step 4 needs the contact_id from step 2 but you accidentally map from step 1's trigger payload (which does not have it). Step 4 silently writes blank or default values. Downstream reporting breaks 3 weeks later.
How to avoid: In the data picker, every field shows its source step. Hover and read the path. For IDs, always map from the step that returned the ID, never from the trigger.
Letting steps accumulate without filters
What goes wrong: Your 5-step Zap fires on every trigger event — including the 80% that should be skipped. Task usage spikes 5x. Plan tier jumps from $30 to $300/mo.
How to avoid: Add Filter by Zapier as step 2 (right after trigger). Set conditions that skip runs that should not execute downstream actions. Filtered-out runs cost 0 Tasks.
No naming convention
What goes wrong: You have 15 multi-step Zaps named "Untitled Zap." Finding the one that broke takes 10 minutes per incident. Multiply by 12 incidents/quarter and you have lost a full workday to navigation.
How to avoid: Name Zaps and steps using a consistent convention. Group Zaps into folders by business area. Add a one-line description to each Zap explaining the business purpose.
Skipping the end-to-end test with a real event
What goes wrong: You tested each step in isolation using sample data, but never ran the whole chain on a live event. The chain works in pieces but breaks in production because a downstream step needed a field a real trigger does not always include.
How to avoid: Before publishing, generate one real trigger event. Watch it flow through every step. Verify every destination app. Only then turn the Zap on.
Ignoring rate limits on destination apps
What goes wrong: A burst of 100 leads in 5 minutes hits HubSpot's API rate limit. Half the Zap runs fail. You do not notice for days because Zapier marks them as "Errored" not "Halted."
How to avoid: For high-volume Zaps, add a Delay step or use the destination app's native batching. Check the destination app's API rate limits before publishing.
Recap
Done — what's next
How to create your first Zap in Zapier
Read the next tutorial
Hand it off
Building multi-step Zaps right takes practice the first 10-15 times. Maintaining them as your data shape changes is ongoing work. EverestX automation specialists ship 5-10 production-grade Zaps per engagement and own monitoring — typically $400-800/mo at $14-16/hr.
See specialist rates
Up to 100 steps per Zap technically, but in practice anything past 8-10 becomes hard to debug. If you find yourself building a 15-step Zap, split it into two Zaps with the first triggering the second via a webhook or a database write.
Paths if the steps share early actions (e.g., contact creation) and only diverge later. Separate Zaps if the entire flow is independent. Paths consume the same Tasks as separate Zaps but are easier to maintain.
Polling triggers check every 1-15 minutes depending on plan tier. Webhook triggers are instant. If you need consistent sub-minute timing, switch to a webhook-based trigger or upgrade to Pro for faster polling.
An error is a single failed run. A halt means Zapier has stopped retrying that Zap because errors repeated. Errors usually auto-replay (Pro+) or wait for manual replay. Halts require investigation — the underlying issue is persistent.
No. Filter by Zapier, Paths by Zapier, and trigger pulls do not count. Only successful action steps consume Tasks. This is why filtering early in a chain is the cheapest way to reduce Task burn.
Zapier
You signed up for Zapier and the dashboard is staring at you. This walks through one real, working Zap end-to-end — trigger app, action app, sample data, test, turn on — without the marketing fluff.
Zapier
One Zap. Five different outcomes depending on the trigger payload. This is where Filter by Zapier and Paths by Zapier earn their keep — and where most DIY setups stack conditions wrong and end up routing nothing.
Zapier
Default Zapier behavior on errors: fire once, fail silent, halt the Zap. Lose data. This walks through auto-replay, dedicated error Zaps, fallback paths, and the monitoring discipline that catches breaks within an hour — not after the next quarterly review.
HubSpot Marketing Hub
Workflows are the engine under HubSpot's marketing automation. They are also where 80% of the silent breakage happens — wrong enrollment criteria, missing re-enrollment toggles, branch logic that loops. Here's how specialists build them so they hold up.
Klaviyo
Welcome flows are the highest-revenue flow in most Klaviyo accounts — typically 30-45% of automated email revenue. A bad welcome flow leaves 60% of that on the table. This is the build that captures it.