Phase 1: No-Code Automation Platforms — Zapier, Make, n8n · 50 min · Make.com · OpenAI API · Google Sheets

Make.com Visual Scenarios — Routers, Iterators, and Error Handling

Visual complexity without code complexity.

Hiring signal: Make.com is the mid-market automation platform of choice. Being able to explain operation-based pricing vs Zapier's task-based pricing, and demonstrate when Make's routers and iterators make it the better choice, shows you can think beyond a single platform — a key signal for automation consultant and solutions engineer roles.

What you will learn

Build a Make.com scenario with routers, conditional branching, and error handling
Understand operation-based pricing vs Zapier's task-based pricing
Use iterators to process arrays of data (e.g., multiple attachments in an email)
Configure error handling: break, ignore, resume, and commit strategies

The Problem

A company uses Zapier to process customer emails with attachments. Each email can have 1–5 PDF attachments. Zapier handles the email trigger and AI classification, but it can't loop through attachments — it processes only the first one. The team builds a workaround: a separate Zap per attachment slot (5 Zaps, 5 triggers, massive task consumption). It's fragile and expensive.

Make.com solves this with iterators — a built-in module that loops through arrays. One scenario handles all attachments. But Make has its own pricing model (operation-based), its own visual language (scenarios, not Zaps), and its own error handling system. Understanding the differences is key to choosing the right platform.

Make is the middle ground — more powerful than Zapier, simpler than n8n
Make.com gives you visual routers, iterators, error handling, and more granular pricing than Zapier. It's the right choice for mid-market teams who need complexity but don't want to self-host or write code. The trade-off: no custom code nodes and no self-hosting.

The Concept

Make.com Architecture

┌─────────────────────────────────────────────────────────────┐
│  SCENARIO STRUCTURE                                         │
│                                                             │
│  TRIGGER ──→ MODULE ──→ ROUTER ──┬─→ MODULE ──→ MODULE      │
│  (watch)    (process)           │                           │
│                                  ├─→ ITERATOR ──→ MODULE    │
│                                  │              ──→ MODULE   │
│                                  │              ──→ MODULE   │
│                                  └─→ MODULE ──→ MODULE       │
└─────────────────────────────────────────────────────────────┘

Operation-Based Pricing

Make charges per "operation" — each module execution counts as one operation:

Plan	Monthly Operations	Price	Price per 1K ops
Free	1,000	$0	$0
Core	10,000	$11	$1.10
Growth	50,000	$69	$1.38
Pro	250,000	$229	$0.92
Team	1,000,000	$599	$0.60

Compare with Zapier: 10,000 tasks = $103 (Zapier) vs 10,000 ops = $11 (Make). Make is ~9x cheaper at this volume.

Your Make scenario has a trigger + 3 modules + a router with 2 branches (each branch has 2 modules). Each run processes 3 items through the iterator. How many operations per run?

Trigger (1) + 3 modules (3) + router (1) + 2 branches × 2 modules × 3 items (12) = 17 operations. Wait, let me recalculate: trigger=1, pre-router modules=3, router=1, branch modules: 2 branches × 2 modules = 4 per item × 3 items = 12. Total = 1 + 3 + 1 + 12 = 17 operations per run. The key insight: iterators multiply operations by the number of items.

Routers: Conditional Branching

Routers split a scenario into multiple paths based on conditions:

[Email Received] → [AI: Classify] → [Router]
                                      ├── Path 1: complaint → [Slack: Alert manager]
                                      ├── Path 2: billing  → [DB: Look up invoices] → [Email: Response]
                                      └── Path 3: other    → [Email: Auto-response]

Each path has a filter that determines when it executes. Unlike Zapier's Paths (which run in parallel), Make's router paths can be sequential or parallel.

Iterators: Looping Through Arrays

The iterator is Make's killer feature vs Zapier. It splits an array into individual items, processing each one through subsequent modules:

[Email with 3 attachments] → [Iterator: attachments array]
                                    ├── Attachment 1 → [AI: Extract text] → [DB: Store]
                                    ├── Attachment 2 → [AI: Extract text] → [DB: Store]
                                    └── Attachment 3 → [AI: Extract text] → [DB: Store]

Error Handling Strategies

Make provides four error handling directives:

Directive	What Happens	Use Case
Break	Stop the scenario, mark as error	Critical steps where partial completion is worse than no completion
Ignore	Skip the failed module, continue	Non-critical steps (e.g., optional enrichment)
Resume	Provide a fallback value and continue	When you have a sensible default
Commit	Save what's done, discard the rest	Partial processing is acceptable

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Build It, Use It, Ship It, Exercises, Key Terms, Common Pitfalls — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.