Automation Flows

Automation flows — glue many SaaS apps on a visual platform, with an error path that actually fires

You are building a working automation on a hosted visual platform: a trigger, a chain of app actions with branching and explicit data mapping, and an error-handling and retry strategy without which the flow is not done.

Your job is two things at once: platform judgement (pick n8n vs Make vs Zapier by the constraints) and a buildable artifact (an importable n8n workflow JSON, or a precise numbered build sheet for Make/Zapier, which have no portable export).

This skill stops the moment the right answer is real code. Writing a typed API client → ../api-connector-builder/SKILL.md. Building the endpoint that receives a webhook in your own app → ../webhooks/SKILL.md. Scripting one vendor directly → ../stripe/SKILL.md, ../notion-connector/SKILL.md, ../google-workspace/SKILL.md, ../whatsapp-telegram/SKILL.md.

1. Pick the platform

The single most expensive mistake is choosing on familiarity instead of cost model. The three platforms bill on fundamentally different units, and at volume that gap is 10×.

Worked cost example. A 10-step flow run 10,000×/month:

• Zapier: ~100,000 tasks (10 actions × 10k) → well past the Pro tier, into the high tiers.
• Make: ~100,000 credits → similar pressure.
• n8n: 10,000 executions regardless of step count; self-hosted = $0.

For complex, high-volume flows, n8n's execution model can cut cost 80–90% vs Zapier.

Pricing and version figures move; re-check the primary vendor pages before quoting a customer (the ≈ is a hedge, not a guarantee): Zapier zapier.com/pricing, Make make.com/en/pricing, n8n n8n.io/pricing, and the n8n 2.0 release note blog.n8n.io/introducing-n8n-2-0. Make's switch to credits as the billing unit (2025-08-27) and n8n 2.0's sandboxed-by-default code execution (stable Dec 2025) are the two facts most likely to surprise someone who learned these tools a year ago.

Decision in one line per row: bill on the unit that matches your shape — many short flows favor task/op platforms; few long flows favor n8n. Obscure app you can't find a node for → Zapier. Raw HTTP / custom code / data must stay on your infra → n8n. Non-technical owner who never wants to SSH → Zapier or Make cloud.

2. Anatomy: trigger → steps → output

A flow has exactly one trigger. Then a chain of action steps. Map every field explicitly.

Trigger: prefer webhook/push over polling. A webhook trigger (Zapier Catch Hook, Make custom webhook, n8n Webhook node) fires on an inbound POST — near-instant. A polling trigger (Zapier Retrieve Poll) does a periodic GET; the interval depends on plan, 1–15 minutes between checks. Polling costs latency, costs runs (it fires even when nothing changed), and can miss events between polls.

Bad:  Trigger = "poll Airtable for new rows every 15 min"  → up to 15 min stale, burns runs on empty checks
Good: Trigger = Airtable "new record" webhook              → fires the instant the row lands, zero idle runs

Map data explicitly. Never assume field names survive a hop. The Typeform field email does not arrive at the Slack step called email — it arrives as a node-output reference you must wire by hand. Pin a real sample, look at the actual output keys, map from those.

Add a guard early. Put a filter/condition right after the trigger so junk events stop before they hit an external API: drop test payloads, require the fields you need to be non-empty, exit on the wrong event type.

3. Error handling — the spine

Every flow ships with an error path, because a flow without one is a silent failure waiting for the day the API hiccups and nobody notices the orders stopped syncing. Before you call a flow done you must be able to point at three things: where a failed run goes, how many times it retries, and who gets told. Full per-platform recipes (including the manual exponential-backoff loop) live in references/error-handling.md, and the retry/backoff theory under them in ../error-handling/SKILL.md; here is the working core.

n8n. Build a dedicated Error Workflow that begins with the Error Trigger node — it runs only when a monitored workflow fails. Wire it to Slack/email/a log row, then set it as the main flow's settings.errorWorkflow. On risky nodes (anything hitting an external API) toggle Retry On Fail (Max Tries 3–5, set a Wait between tries) and, where a single failed item shouldn't kill the run, Continue On Fail (the node emits an error object instead of halting). n8n's built-in retry is linear — for true exponential backoff you build a wait/loop yourself (recipe in references).

Make. Attach an error handler to the risky module:

• Break — the production default. Sends the failed run to the Incomplete Executions queue (no data loss) and can auto-retry from there.
• Resume — supply a hard-coded fallback value and continue.
• Ignore — continue past a non-critical failure.
• Commit — end marked success. Rollback — end marked error and try to revert (not all modules support revert → can leave inconsistency).
• Always put a filter before any external-API module to validate data first.

Zapier. Autoreplay automatically replays failed steps, up to 5 retries per step — but it's account-wide and turns OFF for a Zap once that Zap is published with its own custom error handling. Filters gate a Zap so it only proceeds when data is the right shape. Paths give if/then branching, including a fallback branch on error.

4. Idempotency & dedup

Flows commonly run twice for one event: providers deliver webhooks at-least-once, and retries replay. If your flow does a non-idempotent write (create a charge, send an email, insert a row), a double-fire means a double charge or a duplicate record.

Fix: dedup on a stable key (the event id / external id) before any non-idempotent action.

• n8n — a check-before-write node or DB lookup keyed on the id; skip if seen.
• Make — a data store keyed on the id; check, then write the key.
• Zapier — a storage/lookup step (Storage by Zapier) keyed on the id; filter out if present.

Bad:  webhook → create Notion row                       (Stripe retries the event → two rows)
Good: webhook → lookup event_id in store →
        filter "not seen" → create Notion row → save event_id

5. Test & observe before publish

• Pin a real sample payload (or use the platform's test execution) — don't reason about field names blindly.
• Deliberately fire the error branch: force a bad value, watch the failed run land where you expect.
• Confirm the alert actually arrives — send the test Slack/email and see it in the channel, not just "it should fire".
• Re-send the same event and confirm the dedup guard blocks the second run.
• Only then publish. (On Zapier, remember publishing with custom error handling turns Autoreplay off for that Zap.)

6. Emit the artifact

If n8n is chosen, produce an importable workflow JSON the user can paste into Import from File/Clipboard. It must have a non-empty nodes array (including a trigger node), a connections object, and settings.errorWorkflow pointing at the Error Workflow. Reference credentials by the n8n credential store, never paste secrets inline. Full schema and a minimal trigger→action→error example: references/n8n-workflow-json.md.

If Make or Zapier is chosen, produce a numbered build sheet — neither has a portable export you can hand over. One row per step: # | app | action | field mapping (source → target) | error directive. End with the trigger type and the dedup key.

Run scripts/verify.sh on any JSON you emit: read-only, no network, no credentials — it parses the file and checks a non-empty nodes array, a connections object, and ≥1 trigger node (exits 0 on an empty target).

Anti-patterns