What automation is and isn't, the three product families (n8n, Make, Zapier), how a run actually happens, the capability map, and the same first build three ways.
A Signal Through field guide. Independent and vendor-neutral; not affiliated with n8n GmbH, Celonis (Make), or Zapier Inc. Approximately 23398 words.
In this volume:
Somewhere in your working week there is a task you have done so many times you could do it half-asleep. A customer fills in a form on your website, and you copy their details into a spreadsheet. An invoice arrives by email, and you save the attachment to a shared folder, rename it to match a convention, and forward it to bookkeeping. A new hire signs their contract, and you create accounts for them in five different systems, one at a time, working from a checklist someone printed in 2019.
None of these tasks is hard. That is exactly the problem. They are easy enough that nobody ever budgets time for them, frequent enough that they quietly eat hours every week, and boring enough that the person doing them eventually makes a mistake — a typo in an email address, a skipped checklist line, an invoice filed in the wrong folder. The work is not difficult; it is merely relentless.
Workflow automation is the practice of teaching software to do this kind of work for you. Not the creative work, not the judgment calls, not the conversations — the copying, the forwarding, the renaming, the notifying. The connective tissue between the tools you already use. This chapter defines what that means from a standing start: the three-part anatomy every automation shares, the dozen plain-English terms this entire compendium reuses, and — just as important — an honest account of what this category of software is bad at, so you never waste a weekend trying to automate something that should have stayed human.
One note on scope before we begin. This compendium compares three specific products, but this chapter deliberately names none of them. Everything here is true of the whole category. The products themselves are introduced in Chapter 2 (Meet the Three Product Families), and you will build your first real automation in Chapter 5 (Hands On: Accounts, Editors, and the Same First Build, Three Times).
Most modern businesses run on a collection of specialized online tools: one for email, one for invoicing, one for customer records, one for project tracking, one for chat. Each tool is good at its own job. None of them knows the others exist.
The result is that a large amount of office labor is not really "work" in the sense of producing anything. It is transport. Information arrives in one tool and needs to exist in another, and a human being is the vehicle: read it here, retype it there, attach this, notify them. If you have ever ended a day tired without being able to say what you actually made, there is a good chance you spent that day being middleware — the informal, unpaid software layer that connects systems which refuse to talk to each other.
This transport work has three properties worth noticing, because they define exactly where automation shines:
Work with all three properties is the natural habitat of a workflow automation platform. Work missing any of them — one-off tasks, judgment calls, work that lives entirely inside one app — is where these platforms range from awkward to useless, and the closing sections of this chapter draw that boundary precisely.
Every automation you will ever build, on any platform, at any level of sophistication, has the same skeleton. It is worth learning this skeleton cold, because the whole compendium — and every product's documentation, marketing page, and pricing table — is built on top of it.
A workflow is a saved recipe: a description of an event to watch for and a sequence of things to do when that event happens. (Each product has its own branded name for this — you will meet those names in Chapter 2 — but the generic word, and this book's word, is workflow.) It has three conceptual parts.
The trigger is the event that starts a workflow. It answers the question "when should this happen?" Triggers are always phrased as observations about the world:
Notice that the last two are different in kind from the first three. Some triggers watch for a specific event in a specific app; some fire on a clock, like an alarm; and some are a standing invitation for any outside system to poke the workflow awake. All three kinds exist on every major platform, and the differences between them matter enormously for speed and cost — but that is Chapter 8's territory (Triggers: How Workflows Start). For now the essential idea is simply: every workflow begins with an answer to the question "what event wakes this up?" — and every run begins with one firing of that event.
A workflow with no trigger is just a document. The trigger is what turns a written procedure into a standing arrangement — something that will happen without you, tonight, next Tuesday, and every day after, whether you remember it exists or not. That standing quality is the entire value proposition, and also the entire risk, which is why Chapter 27 (Monitoring, History, and Alerting) exists.
An action is a single thing the workflow does after it wakes up: send an email, create a calendar event, add a row to a spreadsheet, post a message to a chat channel, update a customer record. Actions are always phrased as verbs applied to an app.
A workflow usually contains several actions in sequence, and the generic word for any single position in that sequence — whether it performs an action, makes a decision, or reshapes data — is a step. Every action is a step, but not every step is an action in the "do something in an app" sense: platforms also offer steps that filter (stop the run unless a condition holds), branch (choose between paths), and transform (reformat a date, split a name, do arithmetic). Those richer step types get their own chapters in Volumes C and D. In this chapter, a simple mental model is enough:
A workflow is a trigger followed by a numbered list of steps, executed in order, top to bottom.
That top-to-bottom picture is a simplification — real platforms support branches, loops, and parallel paths — but it is the correct first picture, and Chapter 3 (Mental Models: How a Run Actually Happens) refines it honestly rather than replacing it.
A run (also called an "execution" — the terms are interchangeable, and this book uses both) is one complete pass through the steps, caused by one firing of the trigger. If your form receives thirty submissions today, your workflow will run thirty times: thirty separate runs, each carrying one submission's data through the same steps.
The run is the unit of nearly everything that matters operationally:
Tip: When you are trying to automate a task, narrate it out loud as one sentence in the form "When X happens, do A, then B, then C." If you can say the sentence, you have already designed the workflow: X is your trigger, and A, B, C are your steps. If you cannot say the sentence — if it comes out full of "well, it depends" and "unless" — that is a signal the task involves judgment, and you should read this chapter's final sections before building anything.
Here is a complete automation, expressed with no product and no software — just the anatomy above applied to a scene you have watched play out in real offices.
The manual version. Your company runs a downloadable guide on its website. Visitors fill in a short form — name, email, company — to get it. Every morning, someone on your team opens the form tool, copies the previous day's submissions into the sales spreadsheet, sends each person a thank-you email with the download link, and posts a note in the sales team's chat channel: "3 new leads yesterday." It takes fifteen to twenty minutes a day. On busy days it slips to the afternoon. On vacation weeks it does not happen at all, and leads sit unanswered for days.
The automated version. One workflow:
Every submission causes one run. The run happens within seconds of the form landing, at 2 p.m. or 2 a.m., on workdays and holidays alike. The morning ritual disappears, and — usually the bigger win — the latency (the delay between the event and the response) disappears: the lead hears back in seconds instead of tomorrow, which measurably changes how leads convert.
Three things about this example are worth pausing on, because they generalize.
First, the automation is not smart. It does exactly what the index card said, nothing more. If a competitor's intern fills in the form with a joke name, the workflow will faithfully spreadsheet them, email them, and announce them to the sales channel. Rule-following software follows the rules.
Second, the automation is composed from existing tools. The form app, the spreadsheet, the email service, and the chat tool are all products you already had. The platform's contribution is purely connective — it is the courier, not the warehouse.
Third, each step touches a different vendor's product, which raises an obvious question: how does a workflow platform reach inside four unrelated apps to read forms and write rows and send messages? Answering that question requires the rest of this chapter's vocabulary.
Watch out: Automating a process freezes it. If your manual process has a flaw — the thank-you email is stale, the spreadsheet has a column nobody fills correctly — automation will execute that flaw faster, more often, and with total confidence. The best practitioners tidy the process on paper first, then automate the tidy version. "We automated the mess" is one of the most common failure stories in this field.
Twelve terms carry most of the weight in this compendium. You have already met four — trigger, action, step, run — in their natural habitat. The remaining eight fall into three groups: words for the data moving through a workflow, words for the plumbing that moves it, and the category labels you will meet constantly in vendor marketing.
A record is one bundle of related information treated as a unit: one form submission, one customer, one invoice, one calendar event. If you picture a spreadsheet, a record is a row.
A field is one labeled piece of information inside a record: the email address inside a submission, the due date inside an invoice, the amount inside a payment. In the spreadsheet picture, a field is a cell — or more precisely, a column's worth of cells, since every record of the same kind carries the same set of fields.
These two words matter because workflows operate on records, one at a time, field by field. When a run fires, it carries one record (the form submission that triggered it), and when you configure a step ("send an email to ___"), you fill the blanks by pointing at fields from that record ("the email field from the trigger"). That pointing exercise — called mapping — is the single most common thing you will physically do in any workflow editor, and Chapter 12 (Mapping and Transforming Fields) covers it in depth. What happens when a trigger delivers a list of records instead of one is a genuinely important wrinkle with its own chapter (Chapter 13, Lists, Loops, and Aggregation).
An API — application programming interface — is the back door every serious online product provides so that other software can use it. The human-facing website is the front door: buttons, forms, pages. The API is a parallel entrance made of structured requests: "create a contact with these fields," "give me all invoices since Tuesday," phrased in a machine-readable format. When a workflow platform adds a row to your spreadsheet, no ghost is clicking around your screen; the platform is making polite, structured requests to the spreadsheet product's API, the way a delivery driver uses the loading dock instead of the showroom.
A connector (most platforms' catalogs simply call these "apps"; each product's exact name comes in Chapter 2) is a pre-built, reusable wrapper around one product's API — the platform vendor has done the technical reading for you and packaged the product's capabilities as a friendly menu of triggers and actions. "New row added" and "Add a row" as clickable choices, rather than API documentation you must decipher yourself. The size and quality of a platform's connector catalog is one of its biggest selling points, and Chapter 6 (The App Catalogs) compares them.
An integration is the more general word for a working connection between two systems — "our form tool has an integration with our spreadsheet" — whether it flows through a connector, custom code, or something else. In casual usage, connector and integration blur together; this book uses connector for the packaged catalog item and integration for the achieved connection.
A webhook is an API-era doorbell, and it solves a specific problem: how does the workflow platform find out something happened in another app? One approach is polling — the platform periodically asks, "anything new? anything new?" — which works but is slow and wasteful. A webhook inverts this: you give the other app a special web address belonging to your workflow, and the app calls that address the instant something happens, delivering the new record with the ring. Webhooks are instant, efficient, and slightly more fiddly to set up, and they are important enough to receive a full chapter (Chapter 9, Webhooks and Raw HTTP). For now: polling is the platform checking the mailbox on a schedule; a webhook is the sender ringing your doorbell.
One practical consequence of all this plumbing deserves a preview: before a connector can act on your behalf, you must grant it access to your account in that product — sign in and authorize it, or paste in a key. That granting process, and the serious security questions around it, is Chapter 7 (Connections and Credentials).
SaaS — software as a service — is software you use through a web browser and pay for by subscription, rather than installing from a box. Your email, your spreadsheet, your chat tool, and the automation platforms themselves are all SaaS. The term matters here for one structural reason: the SaaS explosion is why this product category exists. Businesses now run on ten or twenty rented, browser-based tools instead of one monolithic system, and somebody has to carry information between them. (One of the three platforms this compendium covers can also be installed on your own servers — an exception with large consequences for privacy and cost, explored in Chapter 32, Hosting, Security, and Compliance.)
No-code describes tools designed so that people who do not program can build real software behavior by pointing, clicking, and filling in forms. The workflow editors you will meet in Chapter 5 are no-code surfaces: you pick a trigger from a menu, pick actions from a menu, and connect fields by clicking.
Low-code describes tools that are mostly visual but keep an escape hatch open: when the menus run out, you can drop in a small amount of actual programming code — a formula, a snippet, a custom request — to cover the last mile. All three platforms in this book are genuinely usable without writing code, and all three offer code escape hatches of very different depths; that difference is one of the clearest dividing lines between them, and Chapter 10 (When the Catalog Falls Short: Custom Connectors and Code Steps) maps it.
Tip: Do not let "no-code" convince you there is nothing to learn. No-code removes syntax, not thinking. You will still reason about events, sequences, conditions, and data shapes — the same reasoning programmers do, minus the punctuation. Budget real learning time, and it will repay itself quickly.
| Term | Plain-English meaning |
|---|---|
| Trigger | The event that starts a workflow |
| Action | One thing the workflow does in an app (send, create, update...) |
| Step | Any single position in the workflow's sequence — actions, filters, transforms |
| Run | One complete pass through the steps, caused by one trigger firing |
| Field | One labeled piece of information (an email address, a due date) |
| Record | One bundle of fields treated as a unit (one submission, one customer) |
| Integration | A working connection between two systems |
| Connector | A pre-built package wrapping one product's API as menu-friendly triggers and actions |
| API | The structured back door a product offers so other software can use it |
| Webhook | A doorbell: one system calls a web address the instant something happens |
| No-code / low-code | Visual building with no programming / mostly visual with a code escape hatch |
| SaaS | Subscription software used through a browser |
These definitions are deliberately compact; the full working glossary, with every term the compendium uses, lives in Chapter 40 (Mega-Glossary and Resource Atlas).
The fastest way to sharpen a definition is to trace its edges. Four neighboring things are routinely confused with workflow automation, and telling them apart will save you from buying the wrong tool — or assigning the right tool the wrong job.
There is an older, adjacent category called RPA — robotic process automation — in which software literally simulates a human at a computer: moving the mouse, clicking buttons on screen, reading pixels, typing into windows. RPA exists for systems with no API back door — legacy desktop software, ancient internal tools — where the showroom entrance is the only entrance.
The platforms in this book do not work that way. They use APIs: structured, sanctioned, machine-to-machine requests. This makes them dramatically more reliable (a redesigned button does not break anything, because no one is looking at buttons) but also means their reach is bounded by what APIs exist. If a system you depend on offers no API and no export, these platforms mostly cannot touch it, and no amount of enthusiasm will change that.
You could hire a developer to write a program that watches your form and updates your spreadsheet. It would work. It would also need a place to live, someone to fix it when the spreadsheet product changes its API, and a plan for what happens when that developer leaves. Workflow platforms occupy a deliberate middle ground: vastly more flexible than any single app's built-in settings, vastly less burdensome than owning custom software. The platform hosts the workflow, maintains the connectors, keeps the logs, and gives you machinery for catching and retrying failures. You trade some control and some cost-per-use for all of that, and whether the trade is favorable at your volume is a genuine question — Chapter 30 (Scale, Volume, and Performance) and Chapter 31 (Unit Economics) treat it seriously.
A classic workflow is deterministic: the same input produces the same output, every time, forever. That predictability is a feature, not a limitation — it is why you can trust an automation with your invoices. AI models are the opposite temperament: flexible, capable of judgment-like behavior, and not perfectly predictable.
The interesting modern development is that these platforms now let you insert AI as a step inside an otherwise deterministic workflow — "summarize this email," "classify this ticket" — which changes the boundary of what is automatable in ways this book takes very seriously. All of Volume E is about that meeting point, beginning with Chapter 21 (AI Steps Inside Ordinary Workflows) and reaching its most consequential form in Chapter 23 (Agents and MCP: When Software Decides). But be precise about the base layer: the workflow platform itself is a rule-follower. Any judgment in the system is either yours, encoded as rules, or an AI step's, explicitly invited in.
Automation has a fixed setup cost: designing the workflow, connecting the accounts, testing it against real data. That cost only repays itself through repetition. If a task will happen once — migrating one folder of files, sending one batch of emails, cleaning up one spreadsheet — doing it by hand, or asking someone technical for a one-off script, is almost always faster than building a workflow you will never run again. The platforms' own pricing reinforces this: you pay ongoing subscription and usage costs for standing capacity, which is exactly wrong for one-off work.
Watch out: "We'll automate it once and never think about it again" is a myth. Automations run unattended, but they do not run unowned. Connected accounts expire, APIs change, the volume grows past a plan limit, an app renames a field. Healthy teams treat every workflow as a small standing service: it has an owner, its failures alert someone, and its run history gets glanced at. Chapters 19 (Error Handling by Design) and 27 (Monitoring, History, and Alerting) exist because of this.
With the boundary traced from the outside, here is the positive shape inside it. Workflow automation platforms excel at work that is:
Repetitive at meaningful frequency. The same procedure, dozens to thousands of times a month. High frequency is what turns seconds saved into hours saved, and what makes the setup cost trivial in hindsight.
Fully rule-describable. Every decision in the procedure can be written as an explicit condition: if the amount is over the threshold, notify the manager; otherwise file it. No step requires taste, context, or "you'll know it when you see it."
Spread across multiple apps. The work exists precisely because information must cross vendor boundaries. This is the category's home turf — a single app's own settings can often automate work inside that app, but only a platform sitting above all your apps can automate work between them.
Time-sensitive in a human-unfriendly way. Responding to a lead in thirty seconds, at 3 a.m., on the fourth Sunday of a holiday weekend. Machines do not have office hours, and latency wins compound: the automated version of a process is often better, not just cheaper, because it is instant and never backlogged.
Error-prone in a boring way. Wherever the failure mode is a typo, a skipped line, or a forgotten follow-up, an automation's tirelessness beats a human's attention span. People are terrible at the hundredth repetition; software is identical on the millionth.
If you want a single sentence: these platforms turn any written-down, cross-app office procedure into a standing service that executes it instantly, identically, and indefinitely.
Honesty about the other side of the ledger is rarer, and more valuable.
Fuzzy judgment. "Reply if the email seems important." "Approve the discount if the customer seems frustrated." "Flag anything that looks weird." Classic workflows cannot do seems and looks. If a rule cannot be written down crisply, the workflow either cannot be built, or — worse — gets built with a crisp rule that quietly mismatches the fuzzy reality it replaced. (AI steps soften this boundary for some tasks, at real cost in money, latency, and predictability; Chapter 25, Trust, Cost, and Control, is the sober guide to when that trade is worth it. The near-term right answer for judgment-laden steps is often a human checkpoint inside the workflow — Chapter 20, Humans in the Loop.)
One-off and rarely-repeated tasks. As above: the setup cost only pays for itself through repetition. A task that recurs quarterly might justify automation if it is long and error-prone; a task that happens once almost never does.
Work inside apps with no API. No back door, no automation — or only brittle workarounds. Before promising anyone an automated process, verify that every app in the chain actually appears in the platforms' catalogs or offers an API (Chapter 6 shows you how to check).
Heavy computation and big data processing. These platforms move records; they are not built to crunch millions of rows, transcode video, or train models. Runs have practical limits on duration and memory, and per-run pricing punishes brute force. Past a certain data volume, the platform should orchestrate the heavy work — trigger it, monitor it, deliver results — rather than perform it (Chapter 30).
Being the system of record — the one authoritative place a piece of data permanently lives. Workflows carry data; they are a poor place to keep it. The platforms offer small built-in storage (Chapter 14, Storing Data Inside the Platform), useful for counters and lookups, but your customer list belongs in a real database or app, not inside an automation tool.
Processes that change constantly. Automation rewards stability. A procedure that is redesigned weekly will cost more in workflow maintenance than it saves in labor. Stabilize first, automate second.
| Signal | Good fit for automation | Poor fit |
|---|---|---|
| Frequency | Recurs often, on a pattern | One-off or rare |
| Decisions | All expressible as explicit rules | Requires taste or judgment |
| Apps involved | Two or more, each with an API or connector | A single app, or apps with no API |
| Data volume per run | One record or a modest list | Millions of rows, huge files |
| Process stability | Settled and repeatable | Redesigned constantly |
| Cost of a mistake | Recoverable, detectable | Catastrophic and silent |
The last row deserves a sentence. Automation changes the shape of mistakes rather than eliminating them: fewer errors, but faster and more uniform when they occur, and unnoticed unless you designed for noticing. A process where a bad run is cheap and visible is a great first candidate. A process where a bad run wires money or emails your whole customer list deserves guardrails, approvals, and staged rollout — machinery this book covers in Volume D and Volume F — before it deserves autonomy.
Tip: The index-card test compresses this whole section: if you could write the procedure on one index card and a first-day temp could execute it flawlessly, it is automatable; if the temp would need to ask questions, the questions mark exactly where a human — or a carefully governed AI step — still belongs. Keep the card. It becomes your workflow's design document.
You now hold the complete conceptual kernel: workflows made of a trigger and steps, executed as runs, carrying records made of fields, across app boundaries through connectors built on APIs, sometimes rung awake by webhooks — all delivered as no-code and low-code SaaS. Every remaining chapter elaborates a piece of this kernel; none replaces it.
Two chapters complete the foundations. Chapter 2 (Meet the Three Product Families) finally introduces the actual products — who makes them, who they are for, and the philosophical differences a feature list will not show you. Chapter 3 (Mental Models: How a Run Actually Happens) takes this chapter's tidy top-to-bottom picture and makes it true: what really happens between a trigger firing and the last step finishing, where the platforms genuinely differ under the hood, and why those differences leak into everything from pricing to debugging. Chapter 4 gives you the decision scaffolding, and in Chapter 5 you will stop reading and start building — the same small automation, three times, once on each platform.
If you retain a single idea, make it this: workflow automation is not about software doing your job. It is about software doing the parts of your job that were never really the job — the transport, the retyping, the reminding — so the hours you spend working are spent on the parts that needed you.
When someone in a business says "we should automate this," the next sentence usually names one of three products: Zapier, Make, or n8n. All three do the job described in Chapter 1 (What Workflow Automation Is (and Isn't)): they watch for an event in one app — a trigger — and then carry out a series of actions in other apps, without a human copying and pasting in between. But by 2026, none of the three is a single product anymore. Each has grown into a product family: a core automation builder surrounded by satellite products for storing data, presenting interfaces to people, running AI assistants, and embedding automation inside other software.
This chapter is a guided tour, not a verdict. You will meet each family the way you might meet a person: a short origin story, a sense of temperament, and a walk through the household. Every family member gets one orienting paragraph and a pointer to the part of this compendium that covers it deeply. By the end, you should be able to hear a sentence like "we run our lead flow through a Make scenario with a data store behind it" and know exactly what kind of object is being described — even if you could not yet build one. The building starts in Chapter 5 (Hands On: Accounts, Editors, and the Same First Build, Three Times), and the deciding happens in Chapter 4 (The Rosetta Stone, the Capability Map, and How to Decide). Nothing in this chapter is how-to, and nothing here touches money — pricing and unit economics live entirely in Chapter 31 (Unit Economics).
Ten years ago you could describe each vendor in one line: Zapier connected apps with simple two-step recipes, Integromat (Make's former name) drew flowcharts, and n8n was the open-source alternative you ran on your own server. Those one-liners are now out of date in the same way "Amazon sells books" is out of date.
Two forces drove the expansion. First, automation platforms kept bumping into the same adjacent needs: workflows need somewhere to keep data between runs, people need forms and dashboards to interact with them, and businesses want automations delivered inside the products they already use. Each vendor answered by building those adjacencies as named products. Second, the AI wave of 2023–2026 pushed all three to add AI-powered steps, AI copilots that build workflows for you, and full AI agents — software that is given a goal and decides for itself which tools to use, rather than following a fixed sequence. Volume E of this compendium is devoted to that entire territory.
The practical consequence for you as a buyer: when you compare "Zapier vs Make vs n8n," you are really comparing three bundles, and the bundles are not shaped the same. One family may be strong at the satellite you need and mediocre at the core, or the reverse. This chapter's job is to make each bundle legible.
Tip: Evaluate the core automation builder first and the satellites second. Every satellite product in all three families is optional, and most real deployments use the core plus one or two satellites at most. A dazzling side product is a poor reason to accept a core builder that fights you daily.
Zapier was founded in 2011 in Columbia, Missouri by Wade Foster, Bryan Helmig, and Mike Knoop — three friends who kept getting asked to wire small-business apps together and realized the wiring itself was the product. The company went through the Y Combinator startup accelerator in 2012, took famously little outside investment relative to its size, became profitable early, and has operated as a fully remote company for essentially its entire life. That history shows in the product's temperament: Zapier has always optimized for the person who is not a developer, does not want to think about servers, and measures success by "did the thing get done" rather than by elegance of the plumbing.
Zapier's market position is breadth-first ease. Its defining asset is the largest app directory in the category — more than 8,000 integrated apps — and its defining promise is that the first automation you ever build will work within the hour. The trade-off, explored honestly throughout this compendium, is that Zapier's core builder is a linear list of steps rather than a free-form canvas, and complex logic can feel like assembling furniture through a mail slot. Zapier's answer to that criticism has been to grow the family rather than complicate the core.
One structural fact to hold onto: Zapier is a hosted service only. There is no version you can run on your own machines. What that implies for data control and compliance is Chapter 32's territory (Hosting, Security, and Compliance).
Zaps. A Zap is Zapier's unit of automation: one trigger followed by one or more actions, arranged as a vertical list of steps in the editor. Zaps can branch, filter, loop, and call sub-workflows, but the mental model stays "a list that runs top to bottom." How a Zap run actually executes — and what a task, Zapier's unit of work-counting, means — is covered in Chapter 3 (Mental Models: How a Run Actually Happens), and you will build your first Zap in Chapter 5.
The app directory. The catalog — the largest in the category by a wide margin, and still growing — is the family's gravitational center. Each integration exposes a menu of triggers and actions that Zapier has pre-built and maintains, which is why obscure niche tools — the regional accounting app, the boutique webinar platform — are more likely to appear here than anywhere else. What "integrated" actually means, and how deep those integrations go, is dissected in Chapter 6 (The App Catalogs).
Tables. Zapier Tables is a lightweight database that lives inside your Zapier account: rows and columns you can read and write from Zaps, with buttons and views for humans. It exists because so many automations need a place to park state — "which leads have we already emailed?" — without dragging in an external spreadsheet. Platform-native storage across all three vendors is compared in Chapter 14 (Storing Data Inside the Platform).
Interfaces. Interfaces is a page and form builder: you assemble simple web pages — forms, tables, kanban boards (card-based task trackers), link hubs — that trigger Zaps and display Tables data, without writing any code. It turns Zapier from invisible plumbing into something your team or customers can actually click on. Its most important role, approval screens and human checkpoints, is covered in Chapter 20 (Humans in the Loop).
Chatbots. Zapier Chatbots lets you publish a customer-facing AI chat widget, grounded in documents or data you supply, that can also fire Zaps mid-conversation ("book the demo," "create the ticket"). It is Zapier's entry in the chat-surface race described in Chapter 24 (Knowledge, Memory, and Chat Surfaces).
Agents. Zapier Agents — which grew out of an earlier experiment called Zapier Central — are AI assistants you configure with instructions and access to your connected apps, then set loose on goals: triage this inbox, enrich these leads, watch this feed. Unlike a Zap, an agent decides its own steps at run time. What that autonomy buys you and what it risks is the subject of Chapter 23 (Agents and MCP: When Software Decides).
Canvas. Canvas is a diagramming surface for mapping business processes — boxes and arrows, with AI assistance — that can link directly to the Zaps, Tables, and Interfaces that implement each part of the process. Think of it as the planning and documentation layer over the rest of the family; it earns its keep in team settings, which is Chapter 29's territory (Teams, Governance, and Change Management).
Functions and Code by Zapier. Zapier's code-first surface is where developers write automation logic in real programming code — JavaScript or Python — while still drawing on Zapier's app connections and infrastructure. It exists for the moments when clicking through a visual editor is slower than typing. Zapier has offered several code entry points over the years and keeps consolidating this corner of the product: the standalone Functions environment is being retired in favor of Code by Zapier, which runs code steps directly inside a Zap. Because names and boundaries here shift often, treat them as landmarks and confirm the current form in Chapter 10 (When the Catalog Falls Short: Custom Connectors and Code Steps), where every code escape hatch is covered.
Zapier MCP. MCP stands for Model Context Protocol, an open standard that lets AI assistants and agents call external tools in a uniform way. Zapier MCP exposes Zapier's enormous action catalog through that standard, so an AI assistant running somewhere else entirely can say "create an invoice in Xero" and have Zapier execute it. It effectively turns the app directory into a toolbox for other people's AI. Chapter 23 explains MCP properly.
| Family member | What it is | Deep coverage |
|---|---|---|
| Zaps | The core trigger-plus-actions automation | Vol A Ch 3, Ch 5; Vol B Ch 8 |
| App directory | The category's largest pre-built integration catalog | Vol B Ch 6 |
| Tables | Built-in database for workflow state | Vol C Ch 14 |
| Interfaces | No-code forms, pages, and portals | Vol D Ch 20 |
| Chatbots | Customer-facing AI chat widgets | Vol E Ch 24 |
| Agents | Goal-driven AI assistants using your apps | Vol E Ch 23 |
| Canvas | Process mapping linked to live automations | Vol F Ch 29 |
| Functions / Code by Zapier | Code-first automation building | Vol B Ch 10 |
| Zapier MCP | Zapier's actions exposed to external AI | Vol E Ch 23 |
Watch out: All three vendors now sell something called "agents," and the names are nearly identical — Zapier Agents, Make AI Agents, n8n's AI Agent node — but the three architectures differ in where the agent lives, what it can touch, and how you constrain it. Do not assume experience with one transfers to another. Chapter 23 maps the differences precisely.
Make began life in Prague, in the Czech Republic, as Integromat, a product launched in the mid-2010s by a team that believed automation should be drawn, not listed. Integromat's calling card was its canvas: round modules connected by lines, with animated bubbles showing actual data flowing through each connection during a run. In 2020 the company was acquired by Celonis, a large process-mining firm — its software maps how work actually flows through a company's systems — and in early 2022 the product was relaunched under the name Make with a rebuilt platform. You will still find years of tutorials, forum posts, and screenshots that say "Integromat" — same lineage, older product.
Make's position is the visual power tool. It sits deliberately between the other two: more capable and granular than Zapier's linear builder, more approachable than n8n's developer-flavored surface. Where Zapier hides complexity, Make displays it — every step, every branch, every item of data is visible on the canvas — on the theory that seeing complexity is how you master it. People who love Make tend to love it for exactly this; people who bounce off it usually bounce off the same thing. The trade-offs get a fair hearing in Chapter 4.
Like Zapier, Make is a hosted service; there is no self-hosted edition. Its unit of work-counting is the operation — roughly, one module doing its job once — a concept with real consequences that Chapter 3 explains and Chapter 31 prices.
Scenarios and modules. A scenario is Make's unit of automation, and a module is one step within it — one round node on the canvas that triggers, searches, transforms, or acts. Scenarios can branch through routers, loop through iterators, recombine through aggregators, and attach dedicated error-handling routes, all drawn spatially rather than listed vertically. The anatomy of a scenario run is Chapter 3's subject; branching and merging get Chapter 16 (Branching: Filters, Paths, and Merges); error routes get Chapter 19 (Error Handling by Design).
The app catalog. Make maintains a large directory of pre-built app modules — smaller than Zapier's but broad by any other standard — plus unusually strong generic tools for HTTP requests, JSON handling, and text parsing that let a determined builder reach almost anything with a public API (an API, or application programming interface, being the doorway apps expose so other software can talk to them). Catalog depth-versus-breadth comparisons live in Chapter 6, and the raw HTTP tools in Chapter 9 (Webhooks and Raw HTTP).
Make Grid. Grid is a newer family member: an auto-generated, real-time map of your entire automation estate — a zoomed-out visualization showing your scenarios, agents, and data stores, the apps they touch, and how everything interconnects across the account. Where the scenario canvas shows one workflow, Grid shows the whole nervous system — useful the day you inherit an account with dozens of scenarios and no documentation. It belongs to the monitoring story told in Chapter 27 (Monitoring, History, and Alerting) and the governance story in Chapter 29.
Make AI Agents. Make's agents are goal-driven AI workers you define inside Make, powered by a large language model of your choosing (the kind of AI system behind tools like ChatGPT), that can call your scenarios and tools as needed instead of following a fixed path. The characteristic Make twist is that an agent's tools are often themselves scenarios you built visually — the deterministic and the autonomous compose. Chapter 23 covers agent design across all three families.
Make Bridge. Bridge is Make's embedding product: it lets a software company put a slimmed-down, white-labeled automation-setup experience inside its own application, powered by Make underneath, so end users never see Make itself. If you build software for clients or run a SaaS product (software sold as an online subscription), this is aimed at you, and Chapter 33 (Embedding and Client Work) treats it fully.
Data stores. A data store is Make's built-in database: simple tables inside your Make account that scenarios read and write, used for the same "remember things between runs" jobs as Zapier Tables. They are plainer than Tables — closer to a persistence layer than a spreadsheet with a face — and Chapter 14 compares them directly.
| Family member | What it is | Deep coverage |
|---|---|---|
| Scenarios and modules | The core visual automation and its steps | Vol A Ch 3, Ch 5; Vol D Ch 16, Ch 19 |
| App catalog | Pre-built modules plus strong generic HTTP/JSON tools | Vol B Ch 6, Ch 9 |
| Make Grid | Auto-generated map of your whole automation estate | Vol F Ch 27, Ch 29 |
| Make AI Agents | Goal-driven agents that use scenarios as tools | Vol E Ch 23 |
| Make Bridge | White-label embedding of automation in your product | Vol G Ch 33 |
| Data stores | Built-in tables for state between runs | Vol C Ch 14 |
Tip: When researching Make, filter your sources by date. Anything discussing "Integromat" predates the 2022 relaunch; concepts mostly carried over, but menus, module names, and capabilities have drifted substantially. Prefer material from the Make era, and trust the product's own interface over any screenshot.
n8n (pronounced "n-eight-n," a compression of "nodemation" — node-based automation) was created by Jan Oberhauser and released in 2019, with the company built around it headquartered in Berlin. It arrived with a distinctive licensing stance called fair-code: the source code is public, you can read it, run it on your own hardware for your own business without paying, and extend it — but the license restricts reselling n8n itself as a competing service. This is not the same as open source in the strict, certified sense, and the distinction matters in some corporate settings; Chapter 32 walks through the license implications carefully.
n8n's position is developer-grade automation with the option of no-code. The editor is a visual canvas — boxes called nodes, connected by lines — that a non-programmer can absolutely use, but the product never hides its machinery. Data between steps can be inspected at every point, including as raw JSON (JavaScript Object Notation, the bracketed text format most modern software uses to pass data around). Dropping into real code mid-workflow is a first-class move, not an escape hatch. And because you can run the whole platform yourself, n8n attracts teams with strong opinions about where their data lives, engineers who want automation under version control (tracked and reviewed like program code), and — decisively in the mid-2020s — builders of AI systems who wanted an open, inspectable place to wire language models to real tools. n8n's community and public profile grew enormously on the back of that AI wave.
The structural fact to hold onto here is the mirror image of the other two: n8n is the only family you can host yourself, and the only one where "which edition am I running?" is a real question.
Workflows and nodes. A workflow is n8n's unit of automation and a node is one step: a trigger node starts the run, and every subsequent node transforms data or acts on an app. Workflows are true graphs — they can branch, merge, and loop in arbitrary shapes — and every node's input and output data is inspectable as JSON while you build. Run anatomy is Chapter 3; the data model that makes n8n feel different from the other two (everything is a list of items flowing between nodes) is the centerpiece of Chapter 11 (Three Data Models).
Cloud versus self-hosted. n8n Cloud is the vendor's hosted version: they run the servers, you log in and build, much like Zapier or Make. Self-hosted n8n is the same application running on infrastructure you control — a rented server, your company's private network, even a machine in your office. Self-hosting buys data control and, on suitable hardware, freedom from per-run metering; it costs you the operational duties of updates, backups, and uptime. This is one of the biggest forks in the whole decision tree, and Chapter 32 is where it gets decided.
Community versus Enterprise editions. The freely self-hostable Community edition contains the full automation engine. Paid tiers layer on the things organizations need at scale: single sign-on (one company-managed login across many tools), finer-grained permissions, separated environments for building versus production, audit and log streaming, and formal support. The precise feature split shifts over time, so this compendium describes the pattern rather than a frozen list; governance-tier features are treated in Chapter 29 and the security-relevant ones in Chapter 32.
The AI Agent node. n8n's agent capability lives inside the workflow itself: the AI Agent node is a step you drop onto the canvas, wire to a language model, and equip with tools — other nodes, other workflows, external services — plus memory. The agent thinks and acts within a workflow you otherwise control deterministically, which makes n8n a favorite for people who want agents on a short leash. It anchors much of Volume E, especially Chapter 21 (AI Steps Inside Ordinary Workflows) and Chapter 23.
Projects. Projects are n8n's organizational containers: workflows, credentials, and related assets grouped together, with per-project roles controlling who can see and edit what. They are how a shared n8n instance stops being one big pile. Team structure and access design are Chapter 29's subject.
Insights. Insights is n8n's built-in analytics surface: dashboards summarizing workflow executions, success and failure rates, and run volumes over time, answering "is our automation estate healthy?" at a glance. It joins the monitoring toolkit assembled in Chapter 27.
n8n Embed. Embed is the licensing arrangement for putting n8n inside your own product — a white-label deal where your customers get automation powered by n8n under your brand. It is the sibling of Make Bridge in spirit, with a different technical shape, and Chapter 33 compares them.
Community nodes. Because the platform is extensible by design, there is an ecosystem of community-built nodes you can install to cover apps the official catalog misses — with the trust considerations any third-party code deserves. Chapters 6 and 10 cover the catalog and the extension path respectively.
| Family member | What it is | Deep coverage |
|---|---|---|
| Workflows and nodes | The core graph-shaped automation and its steps | Vol A Ch 3, Ch 5; Vol C Ch 11 |
| Cloud vs self-hosted | Vendor-run service vs run-it-yourself | Vol G Ch 32 |
| Community vs Enterprise | Free core engine vs paid organizational layers | Vol F Ch 29; Vol G Ch 32 |
| AI Agent node | An agent as a step inside a controlled workflow | Vol E Ch 21, Ch 23 |
| Projects | Access-controlled containers for team assets | Vol F Ch 29 |
| Insights | Built-in execution analytics | Vol F Ch 27 |
| n8n Embed | White-label licensing for your own product | Vol G Ch 33 |
| Community nodes | Installable third-party integrations | Vol B Ch 6, Ch 10 |
Watch out: "Fair-code" is often shorthanded to "open source," including by enthusiastic n8n users. If your organization has a policy about software licenses — or you plan to build a business on top of n8n — read the actual license terms rather than the shorthand. The self-hosting freedom is real; the freedom to resell the platform is restricted. Chapter 33 covers the legitimate embedding route.
Strip away the satellites and each family has a recognizable posture — a default answer to the question "what should automation feel like?"
Zapier answers: automation should feel like delegation. You describe what you want in the vocabulary of your apps, and the platform absorbs as much complexity as it can on your behalf. Breadth of integrations and speed-to-first-success are the priorities; depth of control is available but never the headline.
Make answers: automation should feel like craftsmanship. The canvas shows you everything, the operation-level granularity rewards precision, and mastery compounds — the same visual language that draws a two-step scenario draws a fifty-module one.
n8n answers: automation should feel like engineering, without demanding that everyone be an engineer. Inspectable data, real code on tap, your infrastructure if you want it, and a licensing stance that lets you own the whole stack.
| Zapier | Make | n8n | |
|---|---|---|---|
| Founded | 2011, Columbia, Missouri | Mid-2010s as Integromat, Prague; relaunched as Make in 2022 | 2019, Berlin |
| Core unit | Zap | Scenario | Workflow |
| A step is called | An action (in a linear list) | A module (on a canvas) | A node (in a graph) |
| Unit of work-counting | Task | Operation | Execution (self-hosting changes the economics) |
| Hosting | Vendor-hosted only | Vendor-hosted only | Cloud or self-hosted |
| Source availability | Proprietary | Proprietary | Fair-code (source available) |
| Posture | Breadth-first ease | Visual power tool | Fair-code, developer-grade |
| Signature satellites | Tables, Interfaces, Chatbots, Agents, Canvas, code steps, MCP | Grid, AI Agents, Bridge, data stores | AI Agent node, Projects, Insights, Embed |
The vocabulary differences in that table — Zap versus scenario versus workflow, task versus operation versus execution — are the surface of a deeper translation problem. Chapter 4 builds the full Rosetta Stone that maps every important term across the three families, so resist the urge to memorize equivalences now; some of them are false friends.
Tip: The unit-of-work row is the one that will matter most to your invoice later. A "task," an "operation," and an "execution" are not the same size, and identical business processes can consume wildly different counts on each platform. Chapter 3 explains the mechanics; Chapter 31 does the arithmetic.
Looking across the three tables, a pattern emerges: the families have been converging on the same checklist. Every one of them now offers a core builder, some form of built-in storage, AI steps and copilots, a full agent offering, and an embedding story for software companies. Competitive pressure does that. If you evaluated these platforms even three years before this writing, your notes about what each one lacks are probably wrong now.
But three differences are structural — rooted in company history and architecture rather than feature roadmaps — and are unlikely to converge:
First, catalog gravity. Zapier's integration directory is an asset compounded over more than a decade of partner relationships, and it remains the practical reason many teams choose Zapier: the obscure app is simply there. Chapter 6 shows how to check catalog claims against your actual app list.
Second, canvas granularity. Make's operation-by-operation visibility — watching individual records flow as bubbles through a diagram — reflects an architectural commitment the linear Zap editor does not share and n8n only partly parallels. Chapter 13 (Lists, Loops, and Aggregation) is where this difference stops being aesthetic and starts being functional.
Third, possession. Only n8n can run entirely on machines you control, and only n8n publishes its source. No feature announcement from the other two changes that, because it is a business-model difference, not a feature gap. Chapters 32 and 34 (Migration, Coexistence, and Lock-In) explore what possession is worth.
Hold these three structural facts loosely in mind through everything that follows. Most feature-level comparisons in this book come with an expiration date; these three do not.
Watch out: Vendor marketing pages describe the whole family as if every member were equally mature. In practice, each family's satellites vary in polish, and newer members change faster than this or any book can track. Treat product names in this chapter as stable landmarks and specific capabilities as things to verify against the vendor's current documentation — Chapter 40 (Mega-Glossary and Resource Atlas) lists the canonical places to check.
You now know the cast. Zapier: born in Missouri, breadth-first, a hosted family of Zaps, Tables, Interfaces, Chatbots, Agents, Canvas, code steps, and an MCP doorway for external AI, all orbiting the category's largest app directory. Make: born in Prague as Integromat, the visual power tool, a hosted family of scenarios and modules extended by Grid, AI Agents, Bridge, and data stores. n8n: born in Berlin, fair-code and developer-grade, a family of workflows and nodes you can run anywhere, with editions, Projects, Insights, the AI Agent node, and Embed layered around the engine.
What you do not yet have is a mental model of what happens when any of these actually runs — what a trigger really checks, when data moves, what gets counted, and where failures hide. That machinery is the same conversation for all three families, and it is the entire business of Chapter 3 (Mental Models: How a Run Actually Happens). Read it before you form any opinions; the run model is where the three families' personalities stop being marketing and start being physics.
You met the three product families in Chapter 2 (Meet the Three Product Families): Zapier, Make, and n8n, each a different answer to the same question of how ordinary software gets glued together. Before you touch any of their editors — that happens in Chapter 5 (Hands On: Accounts, Editors, and the Same First Build, Three Times) — you need three mental models that everything else in this compendium builds on.
They answer three deceptively simple questions:
None of this requires you to build anything yet. These are ideas, not instructions. But they are the ideas that separate people who fight their automation platform from people who work with its grain. When a workflow fires twelve minutes late, or a step mysteriously runs forty times instead of once, or your monthly allowance evaporates on a workflow that "barely does anything," one of these three models explains why.
First, a definition worth pinning down.
A workflow is the thing you build: a saved definition that says "when this happens, do these steps." Zapier calls it a Zap, Make calls it a scenario, and n8n simply calls it a workflow. (Chapter 4, The Rosetta Stone, the Capability Map, and How to Decide, maps this vocabulary in full.)
A run is one execution of that definition. If the workflow is the recipe, a run is one cooked meal. Your "new customer welcome" workflow exists once; it might run three hundred times this month, once for each new customer.
The distinction sounds pedantic until you realize that almost
everything operational — history, debugging, billing, alerting — happens
at the level of the run, not the workflow. When something goes wrong,
you don't debug the recipe in the abstract; you find the specific meal
that burned. Each platform keeps a log of every run: Zapier in its
Zap History, Make in each scenario's History
tab, n8n in its Executions panel. Chapter 27 (Monitoring,
History, and Alerting) lives in those logs; for now, just know they
exist and that each entry is one run.
Every run has three parts, and the three mental models of this chapter map onto them exactly:
Automation platforms are event-driven. A trigger is the part of a workflow that watches for a specific event — "new row in the spreadsheet," "new order in the store," "form submitted." When the event happens, the trigger starts a run. That much is intuitive. The part that isn't intuitive, and that catches nearly every newcomer, is how the platform finds out the event happened. There are two fundamentally different mechanisms, and they behave very differently.
Polling means the platform asks the app, on a repeating schedule, "anything new since I last looked?" Picture walking to your mailbox every so often. Most of the time it's empty and the trip was wasted. Occasionally there's mail — and it may have been sitting there for a while before you found it.
That's polling in one image. A polling trigger calls the app's API — the application programming interface, the machine-readable doorway an app exposes so other software can read and write its data — on an interval, compares what it finds against what it saw last time, and starts a run for anything new. The bookkeeping trick of remembering what it has already seen is called deduplication, and it's why a polling trigger doesn't re-fire on the same record every time it checks.
Two consequences follow directly:
Watch out: "My automation is broken" is, in a surprising fraction of cases, actually "my automation polls on a timer — maybe every few minutes, maybe every fifteen — and you tested it thirty seconds ago." Before you debug anything, ask whether the trigger polls, and how often. Patience diagnoses more polling problems than any log ever will.
A webhook inverts the arrangement. Instead of the platform repeatedly asking, the app sends a message the instant the event happens. If polling is checking your mailbox, a webhook is a doorbell: nothing happens until there's news, and when there's news, you know immediately.
Mechanically, the platform gives the app a unique URL — a web address that acts as a mailbox for incoming messages — and the app is configured to send a small package of data (the payload) to that address whenever the event occurs. The arrival of the payload starts the run. Delivery is typically near-instant: seconds, not minutes.
Webhooks are better along almost every axis — faster, no wasted checking, no polling-interval guesswork. So why doesn't everything use them? Because the app has to support sending them, and many apps don't, or only do so for some events, or only expose them through developer-oriented settings. The platform can only ring the doorbell the app installed. Where the app offers webhook support, platforms usually surface it as an "instant" trigger; where it doesn't, polling is the fallback that always works, because polling only requires the ability to read the app's data.
You'll sometimes see the two mechanisms called pull (polling — the platform pulls data out on its own schedule) and push (webhooks — the app pushes data in as events happen). The full mechanics — how to register webhooks, secure them, catch raw payloads, and cope with the apps that offer neither mechanism cleanly — belong to Chapter 8 (Triggers: How Workflows Start) and Chapter 9 (Webhooks and Raw HTTP). At the mental-model level, here's the whole comparison:
| Polling ("pull") | Webhooks ("push") | |
|---|---|---|
| Who initiates | The platform, on a timer | The app, when the event happens |
| Speed | Delayed — up to one full polling interval | Near-instant |
| Requires from the app | Readable data (nearly universal) | Explicit webhook support (less common) |
| Failure mode | Events discovered late, or found in batches | Events missed entirely if a delivery fails and nothing retries |
| Mailbox analogy | You check the mailbox on a schedule | The doorbell rings |
For completeness: runs can also begin on a schedule (a clock, not an event — "every weekday at 7 a.m.") or manually (a person clicks run, common while testing). Both are useful, both appear in Chapter 8, and neither changes the core model: something initiates the run, and everything after that point is identical regardless of how it began.
All three platforms support both mechanisms; they differ in emphasis and in how visible the distinction is.
Zapier mostly hides it. Triggers in its catalog are either instant (webhook-backed) or polling, usually labeled as such, and Zapier manages the machinery either way. You pick "New Lead" and Zapier worries about how it finds out. Make makes the distinction more visible: many apps offer both a polling-style trigger (often named "Watch …") and an instant, webhook-backed one, and choosing between them is an explicit design decision. n8n is the most explicit of the three: triggers are nodes (n8n's word for a step) you place deliberately — a schedule trigger, an app-specific trigger, or a raw webhook node that hands you a URL and gets out of the way. The pattern previews something you'll see throughout this compendium: as you move from Zapier toward n8n, the platform hides less and hands you more.
Tip: When you evaluate any trigger, on any platform, ask one question first: is this instant or polled? The platforms label it, though sometimes quietly. That single fact tells you what latency to promise your team, and it's the first thing to check when someone asks why an automation "didn't fire."
A run has started. Now what?
Picture an old-fashioned bucket brigade: a line of people passing buckets of water hand to hand from the well to the fire. Each person receives a bucket, does their one job, and passes it on. Nobody runs the whole distance. Nobody acts before receiving the bucket.
That is precisely how a run works. The trigger fills the first bucket
— the data describing the event, almost always structured as
JSON (JavaScript Object Notation, the
near-universal text format for structured data, made of labeled fields
like "email": "dana@example.com" and capable of nesting
lists and records inside each other). Each subsequent step receives the
data, does its one job — look something up, transform a value, create a
record, send a message — and passes its results forward. A step can use
anything produced by any earlier step, not just its immediate
neighbor, but the direction of flow is one way: forward. Step four
cannot use what step six will produce, because step six hasn't happened
yet.
Two properties of the brigade are worth making explicit, because they explain a lot of otherwise-mysterious behavior:
Here is where the platforms genuinely diverge — not in whether data flows step to step, but in the shape of what each step passes forward. This is a preview; the full mechanics fill Chapter 11 (Three Data Models). But the shapes are worth meeting now, because they explain design differences you'll notice from your very first build.
Zapier: flat fields. A Zapier run carries,
essentially, one record — a flat collection of named fields.
First Name: Dana, Email: dana@example.com,
Amount: 49. Each step contributes more named fields to the
pile, and later steps pick from the pile by pointing at a field. It's
the easiest shape to reason about, because it mirrors how a person
describes an event: "a submission came in; here's the name, here's the
email." The cost of that simplicity surfaces when an event contains a
list — an order with five line items, say. A flat shape has no
natural place for a list, and Zapier's answers to that problem
(line-item fields, looping helpers) are workable but bolted on; Chapter
13 (Lists, Loops, and Aggregation) covers them honestly.
Make: bundles. Make wraps data in bundles — self-contained packets of structured data. The crucial behavior: a module — Make's word for a step — can emit more than one bundle, and when it does, every subsequent module runs once per bundle, automatically. A trigger that finds five new orders emits five bundles, and a downstream "Send a message" step sends five messages without you building a loop. The brigade forks into five parallel lanes on its own. This is elegant and powerful, and it's also the single biggest source of Make beginner confusion — steps "mysteriously" running many times, or the opposite puzzle of needing to merge five lanes back into one summary (aggregation, also Chapter 13's territory).
n8n: items. n8n makes the list the default. Every node receives an array (an ordered list) of items — each item a JSON record — and is expected to process all of them. One item is just an array of length one; there's nothing special about it. Where Make forks the brigade per bundle, n8n hands each worker the whole crate of buckets at once and says "deal with all of these." It's the most programmer-shaped of the three models — if you've written code, arrays-in, arrays-out will feel instantly familiar — and the least hand-holding for everyone else.
| Zapier | Make | n8n | |
|---|---|---|---|
| In-flight data shape | One record of flat named fields | One or more bundles (packets) | An array of items at every node |
| A step that produces five results | Awkward — needs line items or looping helpers | Emits five bundles; later steps each run five times | Emits five items; the next node receives all five |
| Feels most like | Filling in a form from a pile of facts | An assembly line that forks per package | Passing arrays between functions |
Tip: When you're evaluating platforms, run one test in your head: what does my data look like when the event is plural? One support ticket, one email, one payment — all three platforms handle the singular case gracefully. Five line items in one order is where the three shapes stop being interchangeable, and Chapters 11 and 13 are where that difference becomes concrete.
While data moves through the brigade, the run as a whole moves through a sequence of states — a lifecycle. Each platform uses slightly different labels in its history screens, but the underlying states are the same five everywhere, and learning them once means every history screen on every platform becomes legible.
Queued. The run exists but hasn't started executing — the platform accepted the event and put the run in line. Queues appear when many events arrive at once, or when your plan limits how many runs may execute simultaneously. A queued run is healthy; it's just waiting its turn.
Running. The brigade is actively passing buckets. Most runs spend seconds here and you'll rarely catch one in the act.
Waiting. The run is deliberately paused, mid-brigade, holding its data — because you built in a delay ("wait two days, then send the follow-up"), a scheduling window, or a pause for human approval. Waiting is not stuck; it's a designed state, and some runs live in it for days. Chapter 17 (Waiting, Scheduling Windows, and Throttling) and Chapter 20 (Humans in the Loop) are built almost entirely on this state.
Succeeded. Every step completed. The run is finished and its record lands in history with whatever green label the platform favors.
Failed. A step could not complete — the app rejected the request, a credential expired, the data didn't fit — and the run stopped. The failure, and everything the run carried at the moment it failed, is preserved in history for diagnosis (Chapter 28, Diagnosing Failures) and often for replay after you fix the cause (Chapter 27).
You'll meet dialect differences — Zapier's history includes statuses like filtered (a run stopped on purpose by a filter condition; not a failure) and delayed; Make sets certain failed runs aside as incomplete executions you can resume; n8n's execution list shows canceled runs alongside errors. All of them map onto the five states above.
Watch out: "Failed" does not mean "nothing happened." A run that dies at step six completed steps one through five. If step three charged a card and step six failed, the card is still charged. This is the single most important thing to internalize about the lifecycle: failure stops the brigade where it stands, it does not un-pour the buckets already poured. Designing for that reality — where to put risky steps, what's safe to retry or replay — is the entire subject of Chapter 19 (Error Handling by Design).
Every automation platform meters usage. Your plan includes an allowance of something, and each run consumes some of it. This section is strictly about the unit — what the meter counts and how that shapes design. Dollars, plan tiers, and cost arithmetic belong exclusively to Chapter 31 (Unit Economics); nothing here requires thinking about money at all.
Here's the punchline up front, because it's one of the most consequential differences in this entire compendium: the three platforms meter three different things.
| Platform | Unit | What one unit means | What the meter effectively measures |
|---|---|---|---|
| Zapier | Task | One action step that successfully does its work | How many steps did work, across all runs |
| Make | Operation | One module executing once — including once per bundle | How many step-times-bundle executions happened |
| n8n | Execution | One complete run of a workflow, start to finish | How many runs happened, regardless of size |
Read that table twice. It looks like bookkeeping trivia. It is actually a design philosophy for each platform, hiding in the billing meter.
In Zapier, each action step that successfully completes counts as one task. The trigger's watching doesn't count, and certain built-in helper steps (filters, for instance) are generally free, while others count — the exact roster shifts over time, so check current documentation rather than memorizing a list. The stable intuition: a run through a three-action Zap consumes roughly three tasks; through a ten-action Zap, roughly ten.
The meter is measuring the length of your workflows multiplied by how often they run. Which means on Zapier, every step you add to a workflow raises the cost of every future run of it.
In Make, each module execution counts as one operation — and remember mental model two: in Make, a module executes once per bundle. A five-module scenario processing one bundle consumes about five operations. The same scenario, when the trigger finds twenty new records and emits twenty bundles, consumes on the order of a hundred — each of those twenty bundles flowed through each subsequent module, and every one of those passes was an operation.
One more habit of this meter is worth knowing at the concept level: a polling trigger's scheduled check consumes an operation even when it finds nothing new — unlike Zapier, where the trigger watches for free. A scenario that checks every few minutes spends operations around the clock just looking, one reason Make builders lean toward webhook-backed instant triggers, which cost nothing while idle.
The meter is measuring volume times complexity. Which means on Make, the expensive workflows aren't the long ones — they're the ones that process many bundles through many modules.
In n8n's hosted cloud plans, the headline unit is the execution: one complete run of a workflow, counted once, no matter how many nodes it contains or how many items flow through them. A two-node run is one execution. A run through forty nodes that loops over a thousand items is also one execution.
And n8n has a second answer that changes the question entirely: because n8n is self-hostable — you can run the software on your own server, a concept Chapter 2 introduced and Chapter 32 (Hosting, Security, and Compliance) explores properly — a self-hosted instance has no platform meter at all. Your constraint becomes your server's capacity and your willingness to operate it, which is a real cost of a different kind, weighed honestly in Chapters 31 and 32.
Either way, the meter (where there is one) is measuring how often your workflows run — and is indifferent to what happens inside a run.
Here is the payoff, and the reason this chapter insists on the unit-of-work model before you've built anything. The same business problem, solved well, looks structurally different on each platform — because each meter rewards a different shape.
On Zapier, steps cost; runs are the natural size. Since every action step in every run draws from the allowance, the instinct is toward short workflows: fewer, more capable steps, and no decorative ones. A step that exists only to tidy a value you could have tidied inside the next step is a recurring toll on every future run.
On Make, bundles multiply; filter early and aggregate. Since operations scale with bundles times modules, the instinct is to shrink the flow as early as possible: filter out irrelevant bundles right after the trigger (before they fan out through the whole scenario), and where you don't need per-record processing, aggregate many bundles into one before the expensive stretch of modules. A filter placed at module two instead of module eight can be the difference between a lean scenario and one that quietly devours the month's allowance — the techniques live in Chapter 13 and Chapter 16 (Branching: Filters, Paths, and Merges).
On n8n, runs cost (or the server does); make each run rich. Since a run costs the same whether it's trivial or elaborate, the instinct inverts completely: consolidate. Where a Zapier designer splits work across several small Zaps, an n8n designer happily builds one workflow that fetches five hundred records, loops, branches, and updates three systems — all inside a single execution. Batch-shaped work, expensive per-run elsewhere, is n8n's home turf.
Notice what happened: the billing unit — a bookkeeping choice — reached backward into architecture. The "right" design on one platform is a mildly wasteful design on another, not because any platform is wrong, but because each meter makes a different dimension of your workflow expensive. When Chapter 35 (The Decision Framework) asks you to characterize your workload — many small events, or fewer big batches? long workflows, or short ones? — this model is the reason those questions predict cost and comfort so well.
Watch out: Never compare allowance numbers across platforms as if the units were the same. "Ten thousand tasks," "ten thousand operations," and "ten thousand executions" describe wildly different amounts of real work — a single one of those n8n executions might do what consumes dozens of Make operations, and one busy polling trigger on Make can emit bundles that fan out into hundreds of operations from events a per-run meter would count on one hand. Convert everything into your workload's shape before comparing anything. Chapter 31 gives you the worksheet.
Tip: You don't need to compute anything yet — but starting with your very first build in Chapter 5, glance at the meter after each test run (each platform shows consumption in its usage or history screens). Watching what one real run of your workflow costs, in the platform's own unit, builds better intuition than any table in any book, this one included.
Run one concrete scenario through all three lenses, and watch each model do its job.
The business event: a prospect submits the demo-request form on your website. You want them enriched with company data, posted to the sales Slack channel, and created in the CRM (the customer relationship management system — the sales team's database of contacts and deals).
Model one — how does the run begin? Your form tool supports webhooks, so on any platform this can be an instant trigger: form submitted, doorbell rings, run starts within seconds. Had the form tool been polling-only, the same build would work identically — but you'd promise the sales team "within a few minutes," not "instantly," and you'd know the difference is the trigger mechanism, not a defect.
Model two — what travels? The webhook payload — name, email, company, message, as JSON — is the first bucket. The enrichment step receives it and passes it forward with company data added; Slack and CRM steps each draw on the accumulated pile. On Zapier that pile is flat fields; on Make it's one bundle flowing through four modules; on n8n it's a one-item array moving node to node. One submission, so all three shapes look almost identical — this is the singular case where the platforms agree. If the trigger were instead "every morning, fetch all of yesterday's submissions," the shapes would diverge exactly as mental model two predicts: Zapier reaching for looping helpers, Make fanning out one bundle per submission, n8n carrying them as one item array through a single brigade. And in any version, a run that fails at the CRM step has already posted to Slack — the lifecycle model, telling you where the brigade stopped.
Model three — what did it cost? On Zapier: three action steps, so roughly three tasks per submission. On Make: four modules, one bundle, so roughly four operations — but the morning-batch variant with thirty submissions becomes bundles times modules, and suddenly the early filter matters. On n8n: one execution either way — per submission in the instant version, or one execution for the entire batch of thirty in the morning version, which is exactly why batch designs gravitate toward n8n.
Three questions, three models, one run: how it began, what it carried and what states it passed through, and what the meter read. Every workflow you will ever build on any of these platforms — including the AI-driven ones in Volume E, where the "step" might be a model making decisions — is this same story with different details.
You now have the vocabulary the rest of the compendium assumes. Chapter 4 (The Rosetta Stone, the Capability Map, and How to Decide) lines the three platforms' terms and capabilities up side by side, and Chapter 5 puts your hands on all three editors to build the same workflow three times — where you'll see a trigger fire, watch a bucket brigade run in each platform's own shape, and read the meter afterward, this time knowing exactly what you're looking at.
The single biggest obstacle to comparing n8n, Make, and Zapier is not features. It is vocabulary. The three platforms do broadly the same job — watch for an event, move data, act on it — but they describe that job in three different dialects, and several words mean one thing in one product and something quite different in another. Before you can compare capabilities honestly, you need a translation layer.
This chapter builds the three reference instruments the rest of the compendium leans on. The first is the Rosetta Stone: a translation table for roughly thirty core terms, anchored to one small automation described in each platform's own dialect. The second is the capability map: six areas that organize every question you will ever ask about these platforms, and that structure Volumes B through G. The third is the decision method: a scorecard built on those same six areas, weighted differently depending on who you are, and completed in Chapter 35 (The Decision Framework). No verdicts are issued here — this chapter hands you the instruments; later chapters supply the evidence.
Words stick better when they are attached to something concrete, so every term in this chapter hangs off the same small build: when someone submits a web form, add a row to a spreadsheet, then send a notification message to a team chat channel. It is the classic first automation — three steps, three different services, real data moving between them. You will build it for real, three times, in Chapter 5 (Hands On: Accounts, Editors, and the Same First Build, Three Times). Here, we only describe it, once per dialect.
Something happens in the outside world (a form submission). Your automation notices, wakes up, and carries the submitted data through two more steps: one that writes a spreadsheet row, one that posts a chat message. Each run handles one submission. If ten people submit the form, the automation runs ten times.
In Zapier you would build a Zap — Zapier's name for one complete automation. A Zap is a sequence of steps. The first step is always the trigger: the event that starts a run, here "New Form Submission." Every step after the trigger is an action — here, "Create Spreadsheet Row" followed by "Send Channel Message." Each service you connect (the form tool, the spreadsheet, the chat tool) is an app in Zapier's catalog, and each app exposes its own menu of triggers and actions.
When a submission arrives, the Zap runs. Zapier meters your plan in tasks: roughly speaking, each action step that successfully does work consumes one task. Our three-step Zap consumes about two tasks per run (the trigger itself is not billed as a task). The data from the form arrives as a set of fields — name, email, message — which you insert into later steps by mapping: picking fields from a dropdown that shows sample data from the trigger.
In Make the same build is a scenario. Instead of steps, a scenario is drawn as a chain of modules — round icons on a freeform canvas, connected by lines. The first module is the trigger module (Make often names these "Watch," as in "Watch Form Submissions"); the following modules perform actions ("Add a Row," "Create a Message"). What Zapier calls an app, Make also calls an app, but each app is a collection of modules.
When the scenario runs, data travels between modules as bundles. A bundle is one packet of data — one form submission is one bundle. Inside a bundle are items: the individual fields such as name and email. This is the single most dangerous word in the whole comparison, because n8n uses "item" for what Make calls a bundle — hold that thought; we flag it properly below. Make meters your plan in operations: every time a module does one cycle of work, that is one operation. Our three-module scenario consumes about three operations per run, because in Make the trigger's work is metered too.
In n8n you build a workflow, drawn on a canvas as connected nodes. The first node is a trigger node ("On form submission," or a Webhook node — a webhook being an address an outside service can push data to the moment something happens; see Chapter 9, Webhooks and Raw HTTP); the rest are action nodes ("Append Row," "Send Message"). What the other two call an app, n8n calls a node — technically each service is an integration that appears as a node type you drop onto the canvas.
One complete run is an execution. Data moves between nodes as items, and each item is a JSON object — JSON (JavaScript Object Notation) being the standard text format for structured data, made of named fields and values. One form submission is one item; its fields are the JSON properties inside it. You pull data from earlier nodes using expressions — small snippets wrapped in double curly braces that reference upstream data, usually built by dragging a field from a data panel rather than typing. On n8n's hosted cloud service, plans are metered by executions — one run is one execution, no matter how many nodes it contains. If you self-host n8n (run it on your own server, which its free "fair-code" license permits — the source code is open to read and modify, though the license restricts reselling and is not open source in the strict sense), executions are not metered at all; your only limits are your server's capacity. Chapter 31 (Unit Economics) works through what these metering differences cost in practice.
Watch out: The three billing units — task, operation, execution — are not the same thing measured three ways. They are three different things. A run of our little build is roughly two Zapier tasks, three Make operations, or one n8n execution. Chapter 3 (Mental Models: How a Run Actually Happens) explains why the three meters count differently; Chapter 31 (Unit Economics) turns the units into money. Comparing plan quotas across platforms without converting units first is the most common mistake in every pricing discussion you will read online.
The table below is the starter set: the terms you need for Volumes A through D. It is deliberately not exhaustive — the full alphabetical version, with every synonym and legacy name, lives in Chapter 40 (Mega-Glossary and Resource Atlas). Read the table top to bottom once now, then treat it as a lookup: whenever a later chapter (or a vendor's documentation, or a forum thread) uses a platform-specific word, translate it here before you judge it.
Rows are ordered by theme: the automation and its parts, then data, then flow control, then operational terms. Where a platform has no single word for a concept, the cell describes how that platform expresses it instead — an absence of vocabulary is itself useful information.
| Plain-English concept | Zapier says | Make says | n8n says |
|---|---|---|---|
| The automation you build | Zap | Scenario | Workflow |
| One step inside it | Step | Module | Node |
| The connector for an outside service | App | App (a set of modules) | Node type (an integration) |
| The step that starts a run | Trigger | Trigger module (often "Watch…") | Trigger node |
| A step that does something | Action | Action module | Action node |
| A step that looks something up | Search action | Search module | A "get" or "search" operation on a node |
| One complete run | Zap run | Scenario run (execution) | Execution |
| The unit your plan meters | Task (per successful action step) | Operation (per module cycle, triggers included) | Execution on cloud plans; unmetered when self-hosted |
| One record moving between steps | The run's data (one record per run) | Bundle | Item |
| One field inside a record | Field | Item | Field (a JSON property) |
| The data format under the hood | Flattened fields | Bundles containing items | JSON |
| Inserting earlier data into a step | Mapping (dynamic fields) | Mapping | Expressions |
| Several records in one payload | Line items | Multiple bundles | Multiple items |
| Doing a step once per record | Looping by Zapier (a built-in utility) | Iterator | Default behavior (nodes run per item); Loop Over Items node for batching |
| Combining many records into one | Digest and line-item utilities | Aggregator | Aggregation nodes |
| Only continue if a condition holds | Filter | Filter (set on a connection between modules) | IF or Filter node |
| Branching into alternate routes | Paths | Router | IF and Switch nodes |
| Rejoining branches | Limited (see Chapter 16) | Converging routes (limited) | Merge node |
| Pausing mid-run | Delay by Zapier | Sleep (in the Tools app) | Wait node |
| Running on a clock | Schedule by Zapier | Scenario scheduling | Schedule Trigger node |
| Receiving an inbound web call | Webhooks by Zapier (Catch Hook) | Custom webhook | Webhook node |
| Calling a service's API (application programming interface — the machine-readable way software talks to a service) | Webhooks by Zapier custom request; per-app "API Request" actions | HTTP module | HTTP Request node |
| Running your own code | Code by Zapier (JavaScript or Python) | No general-purpose code step; text/JSON tools, plus custom functions on higher-tier plans | Code node (JavaScript or Python) |
| A saved login to a service | Connection | Connection | Credential |
| Small storage inside the platform | Storage by Zapier; Zapier Tables | Data store | Data tables; workflow static data (see Chapter 14) |
| Reformatting text, dates, numbers | Formatter by Zapier | Built-in functions in the mapping panel; Tools modules | Expressions; transform nodes |
| An automation called by another | Sub-Zap | Calling another scenario (commonly via webhook) | Sub-workflow (Execute Sub-workflow node) |
| The log of past runs | Zap history | Scenario history | Executions list |
| A failed run held for inspection | A stopped run you can replay from Zap history | Incomplete execution | Failed execution (retryable) |
| Error handling attached to a step | Configurable error behavior and autoreplay (see Chapter 19) | Error handler routes with directives (ignore, resume, break…) | Per-node error settings plus a designated error workflow |
| Switched on and processing | Published (On) | Active (scheduling on) | Active |
Connections, credentials, and everything about authenticating to services get their full treatment in Chapter 7 (Connections and Credentials); triggers in Chapter 8; the data rows of this table expand into all of Volume C.
Tip: Keep this table within reach for the entire book — bookmark it or print it. Every later chapter uses each platform's native vocabulary without stopping to re-translate, precisely so the text reads the way the platforms' own documentation and communities read.
A translation table handles honest differences. False friends — words that exist in two dialects with different meanings — cause the real accidents. Five matter enough to memorize now.
Item. In n8n, an item is a whole record: one form submission, one row, one JSON object flowing between nodes. In Make, an item is one field inside a bundle — the bundle is the record. When a Make user and an n8n user say "it processed ten items," they are describing different magnitudes of work. Chapter 11 (Three Data Models) untangles this fully.
Execution. In n8n, an execution is one run of a workflow and, on cloud plans, the unit of billing. Make also calls a scenario run an execution — but bills by operation, not by run. Same word, one platform bills by it, the other does not.
App. In Zapier and Make, an app is a catalog entry for an outside service. n8n does not use the word this way at all — it says "node" or "integration" for the same idea, and has no "app catalog" in its own vocabulary. When a marketing page brags about the many thousands of apps a platform supports, Chapter 6 (The App Catalogs) explains why raw counts mislead.
Trigger. All three use the word, but what happens under the hood divides into two families: polling triggers, which check the outside service on a repeating schedule and therefore introduce a delay, and instant triggers, which the outside service pushes to (usually via a webhook — an inbound web call) the moment the event occurs. The platforms do not always advertise which family a given trigger belongs to. Chapter 8 (Triggers: How Workflows Start) teaches you to tell them apart.
Filter. In Zapier, a filter is a step you insert into the sequence. In Make, a filter lives on the line between two modules, not as a module itself. In n8n it is a node again (IF or Filter). The concept is identical; the place you click to create it is not.
Watch out: Vendor comparison pages and community forums almost never translate terms before comparing. A thread titled "Make is cheaper than Zapier" that compares operation counts to task counts, or an n8n post that says "one execution handled 500 items" (which would be 500 separate runs in Zapier's world), is not wrong so much as unconverted. Run everything through the table first.
Vocabulary lets you read; the capability map lets you navigate. Every meaningful question about these platforms falls into one of six areas, and those six areas are exactly how Volumes B through G are organized. The map serves two purposes at once: it is the table of contents for the middle of this book, and it is the set of dimensions for the decision scorecard at the end of it.
| Area | The question it answers | Where it lives |
|---|---|---|
| Connectivity | Can it talk to the services I use — and to the ones with no catalog entry? | Volume B, Chapters 6–10 |
| Data | Can it carry, reshape, store, and move my data without losing or garbling it? | Volume C, Chapters 11–15 |
| Flow control | Can it express the logic of my process — branches, timing, reuse, failure, human sign-off? | Volume D, Chapters 16–20 |
| AI | Can it use AI inside workflows, build workflows for me, or act as an agent — safely? | Volume E, Chapters 21–25 |
| Operations | Can I test it, watch it, fix it, govern it, and scale it once it matters? | Volume F, Chapters 26–30 |
| Adoption | Can I afford it, host it where I must, embed it, and leave it if I need to? | Volume G, Chapters 31–35 |
A little more color on each, because the one-line questions compress a lot.
Connectivity covers the app catalogs themselves (Chapter 6), how you authenticate and share access to outside services (Chapter 7), the full taxonomy of ways a workflow can start (Chapter 8), webhooks and raw HTTP for services that push or that lack polish (Chapter 9), and what to do when the catalog simply does not have your service — custom connectors and code steps (Chapter 10). Connectivity is where most buyers start and, for simple use cases, where many could reasonably stop.
Data covers each platform's underlying data model — the fields-versus-bundles-versus-items distinction you just met, now in full (Chapter 11) — plus mapping and transforming values (Chapter 12), handling lists and loops (Chapter 13), storing data inside the platform between runs (Chapter 14), and moving files and documents rather than just text (Chapter 15). Data is where the three platforms differ most deeply, because the differences are architectural, not cosmetic.
Flow control covers branching and merging (Chapter 16), waiting, scheduling windows, and throttling — deliberately slowing a workflow to respect an outside service's limits (Chapter 17), modularity and reuse (Chapter 18), designing for failure rather than merely reacting to it (Chapter 19), and pausing for human approval (Chapter 20). This is the area that separates automations that demo well from automations that survive contact with reality.
AI covers adding AI steps — calls to a language model — inside otherwise ordinary workflows (Chapter 21), copilots that draft the automation for you (Chapter 22), agents and MCP, the emerging standard by which AI systems call tools, for cases where software decides its own next step (Chapter 23), knowledge bases and chat surfaces (Chapter 24), and the trust, cost, and control questions all of that raises (Chapter 25).
Operations covers testing and launching (Chapter 26), monitoring and run history (Chapter 27), diagnosing failures when — not if — they occur (Chapter 28), teams, permissions, and change management (Chapter 29), and behavior under real volume (Chapter 30).
Adoption covers what a workflow actually costs to run at your volumes (Chapter 31), hosting, security, and compliance — including the self-hosting option that exists for only one of the three (Chapter 32), embedding automation into client work or your own product (Chapter 33), and migration, coexistence, and lock-in (Chapter 34), before Chapter 35 assembles the decision.
The map earns its keep as a routing device. When a question comes up in your own evaluation — "can it wait three days and then check whether the customer replied?" — classify it into an area before you search for the answer. That one is flow control, split between Chapter 17 (the waiting) and Chapter 16 (the checking). "Can my client's team see run logs without seeing my other clients' workflows?" is operations (Chapter 29) with an adoption edge (Chapter 33). "The form tool isn't in the catalog" is connectivity, Chapter 10. Classifying first keeps you from wandering, and it builds the habit the scorecard depends on: seeing every requirement as belonging to an area with a weight.
Our anchor automation touches the map lightly but visibly: the form trigger is connectivity; carrying name-and-email into a row is data; the straight three-step line is flow control at its most trivial; there is no AI; checking whether last night's submissions actually arrived is operations; and what ten thousand submissions a month would cost is adoption. Even the smallest real build has coordinates in all six areas — which is the argument for scoring all six, not just the ones that are fun to shop for.
Most platform comparisons fail in one of two ways: they crown a universal winner (there is none), or they drown you in feature matrices with no way to rank what matters. The method used in this book avoids both by separating three things that are usually mashed together — evidence, dimensions, and weights.
Evidence is what Volumes B through G supply: how each platform actually behaves in each capability area, demonstrated rather than asserted. Dimensions are the six areas of the capability map — the scorecard has exactly six rows, no more. Weights are yours: how much each area matters for your situation. Two readers can agree on every fact in this book and still correctly choose different platforms, because their weights differ. That is the design, not a failure of nerve.
Weights cluster. Rather than asking you to invent yours from nothing, the book uses five recurring personas — deliberately drawn archetypes, not boxes you must fit exactly. Find the one or two nearest to you, then adjust.
The solo operator. One person automating their own business — a coach, a shop owner, a freelancer. No developers on call, limited hours, real but modest budget. Cares that connections just work and that the monthly bill stays boring.
The SMB ops team. A small operations or revenue-operations team in an SMB — a small-to-midsize business of tens to a few hundred people — automating across departments. A few workflows become load-bearing; several people need to understand them; nobody's full-time job is maintaining them.
The agency. Builds and runs automations for clients. Multiplies everything: many workspaces, many credentials that belong to other people, monitoring across accounts, and a business model question — who pays for the platform, and how is that billed onward? Chapter 33 (Embedding and Client Work) is largely theirs.
The product team. Software developers using a workflow platform as infrastructure — internal tooling, integrations behind a product feature, or glue between services. Comfortable with code, APIs, and version control; allergic to anything they cannot test, review, and reproduce.
The regulated enterprise. An organization where data residency (which country data is stored in), audit trails, access control, and vendor risk review are gating requirements, not preferences. A platform that cannot pass procurement never gets to show off its features.
The table below shows each persona's starting emphasis across the six dimensions, expressed qualitatively. These are defaults to argue with, not verdicts — you will set your own numeric weights when you complete the scorecard in Chapter 35, with all the evidence in hand.
| Dimension | Solo operator | SMB ops team | Agency | Product team | Regulated enterprise |
|---|---|---|---|---|---|
| Connectivity | High | High | High | Medium | Medium |
| Data | Low | Medium | Medium | High | Medium |
| Flow control | Low | Medium | Medium | High | Medium |
| AI | Medium | Medium | Medium | Medium | Low |
| Operations | Low | Medium | High | High | High |
| Adoption | High | Medium | High | Medium | High |
The reasoning, briefly. The solo operator weights connectivity and adoption highest because catalog breadth substitutes for engineering help, and cost predictability is existential at small scale; deep flow control rarely pays for its learning curve at one-person volume. The SMB ops team is the balanced middle — everything is medium-to-high because their workflows serve multiple stakeholders but they lack specialists in any one area. The agency's distinctive highs are operations (monitoring many clients' workflows is the actual job) and adoption (embedding, white-labeling — presenting the platform under your own brand — and the economics of reselling). The product team inverts the solo operator: connectivity matters less because they can code around gaps (Chapters 9 and 10), while data, flow control, and operations dominate because they hold automations to software-engineering standards. The regulated enterprise weights operations and adoption — governance, hosting, compliance — as gates, and starts AI low not out of disinterest but because Chapter 25's trust and control questions must be answered before AI weight can rise.
Tip: If you sit between personas — a technical solo founder is part solo operator, part product team — average your two nearest columns as a starting point, then adjust individual rows. The persona is scaffolding for your weights, not an identity.
Watch out: Resist the urge to inflate the AI row because it is the exciting one. Weight it by what you will actually run monthly, not by demos. An automation that files invoices correctly every night beats an agent that impresses in a screenshot; if AI genuinely is your center of gravity, Volume E will justify a high weight on evidence rather than enthusiasm.
The method from here is deliberately plain. As you read Volumes B through G, each volume closes the loop on one scorecard dimension: you will have seen, in worked detail, how the three platforms handle that area, and you can score each platform on it using whatever scale you like — this book uses a simple low-to-high scale to avoid false precision. Keep notes as you go; better still, run the hands-on builds (Chapter 5 now, Chapters 36 and 37 later) so your scores rest on your own fingers, not the author's. Chapter 35 then assembles everything: you confirm your persona, set final weights, multiply weights by scores, and — more important than the arithmetic — sanity-check the result against the gating questions that no weighted sum can capture, such as "is self-hosting mandatory?" or "does procurement require a specific compliance regime?" A gate failed is a platform eliminated, whatever its score.
Tip: Score with evidence attached. A note that reads "Data: strong — handled the nested line-items case in Chapter 13 without a workaround" will still mean something to you in six months; a bare number will not. The scorecard is a thinking tool first and a spreadsheet second.
No verdicts are issued in this chapter, and none of the personas maps cleanly onto one platform — that is precisely why the method exists. What you have now is a working translation table, a map with six regions, and an empty scorecard with honest weights penciled in.
Chapter 5 puts the Rosetta Stone under load: you will create accounts on all three platforms, meet the three editors, and build the form-to-spreadsheet-to-notification automation three times, watching the vocabulary from this chapter attach itself to real screens. From there, the volumes walk the capability map in order — connectivity first, because nothing else matters if the platform cannot reach your tools. Keep the translation table close, classify every question into its area, and let the scorecard fill itself in as the evidence arrives.
This is the week-one chapter. Everything before it was orientation: Chapter 1 (What Workflow Automation Is (and Isn't)) defined the territory, Chapter 2 (Meet the Three Product Families) introduced the vendors, Chapter 3 (Mental Models: How a Run Actually Happens) explained what happens when a workflow fires, and Chapter 4 (The Rosetta Stone, the Capability Map, and How to Decide) gave you the translation table between the three products' vocabularies. Now you sit down at the keyboard.
By the end of this chapter you will have opened accounts on all three platforms, set up a sandbox where nothing you break matters, toured each product's builder, and constructed the same small automation three separate times — once in Zapier, once in Make, once in n8n. You will test each one, switch it on, and watch a real run appear in the run history. That last moment — a real event flowing through a workflow you built, visible in a log — is the point where automation stops being a concept and becomes a tool you own.
One promise about scope: this chapter is deliberately shallow on data work. You will click fields into place, but you will not reshape, format, or compute anything. Transforming data is the whole of Volume C, and doing it properly requires ideas we have not built yet. Week one is about learning where everything lives.
Before you build anything, decide what to build — and resist the natural instinct to start with your most painful process. The most painful process is almost always painful because it is complicated, and complicated is exactly wrong for a first build. You want a pilot: a small, real, boring automation that teaches you the tools without risking anything.
A good pilot passes a three-question screen. Write your candidate down and answer honestly:
1. Is there a clear starting event? Automation begins when software notices something happen. That "something" is the trigger — the event that starts a workflow run. "A new row appears in a spreadsheet" is a clear starting event. "When things get busy" is not; no system emits a things-got-busy event. If you cannot name the exact moment the workflow should wake up, and name the system where that moment is visible, the candidate fails.
2. Does the event carry structured data? Structured data means information that arrives in labeled slots — a name field, an email field, a date field — rather than free-flowing text a human would have to interpret. A form submission is structured. A rambling voicemail is not. Week one automations should touch only structured data, because structured data can be clicked into place; unstructured data needs the AI techniques of Volume E or the transformation work of Volume C.
3. Is the action rule-based? The action — what the workflow does in response — must be something you can describe as a rule with no judgment calls: "post a message containing the name and email to the team channel." If the correct action depends on reading between the lines ("reply appropriately"), it is not a week-one pilot. Judgment-shaped steps come much later, in Volume E's chapters on AI steps and agents.
Then apply a safety screen on top:
| Safety question | Pass looks like | Fail looks like |
|---|---|---|
| Blast radius | Only you and a test channel see the output | Customers or the whole company see the output |
| Reversibility | A wrong run can be deleted or ignored | A wrong run sends an email you cannot unsend |
| Duplicate tolerance | Running twice is annoying at worst | Running twice double-charges someone |
| Delay tolerance | Ten minutes late is fine | Late breaks a promised deadline (an SLA — a service-level agreement) |
| Data sensitivity | Fake or harmless data | Payroll, health, or financial records |
Notice what this screen is not: it is not a business case. It says nothing about hours saved or cost per run. That is deliberate. Whether an automation is worth building is a real question, but it belongs to Volume G — Chapter 31 (Unit Economics) covers what runs actually cost, and Chapter 35 (The Decision Framework) covers how to choose what to automate at all. Week one optimizes for learning, not return.
Tip: If you are stuck for a pilot, borrow ours. The build in this chapter — a new spreadsheet row becomes a chat message — passes every question above, uses apps almost everyone has, and exercises the exact muscles (triggers, connections, field mapping, testing, history) that every future build needs.
Our pilot, restated as the worksheet demands: when a new row is added to a specific Google Sheet (the trigger, carrying structured columns like Name and Email), post a message to a designated Slack channel announcing it (the action, purely rule-based). This is the Rosetta build from Chapter 4 — the same automation we will express in all three products' dialects, which is precisely why it makes the ideal first build. If your team lives in Microsoft Teams or another chat tool instead of Slack, substitute freely; the clicks are nearly identical. If you use no chat tool at all, an email-to-yourself action works the same way.
All three vendors let you start without paying, though the shape of "free" differs — a distinction Chapter 2 explored and Chapter 31 prices out.
Zapier offers a free plan. Sign up at zapier.com with an email address or a Google/Microsoft sign-in. The free plan allows a small monthly allowance of tasks — Zapier's billing unit, roughly one task per action performed — and restricts some features: workflows longer than a trigger plus one action, certain "premium" app connectors, and the fastest checking speeds all sit behind paid tiers. None of that bites here — this chapter's build is exactly a trigger plus one action, and both apps it uses (Google Sheets and Slack) are standard connectors, not premium ones. Free is enough.
Make offers a free plan. Sign up at make.com; you will be asked to pick a data-center region for your new organization — choose the one nearest you or nearest your compliance requirements, and choose deliberately, because an organization cannot be moved to a different region later (more on residency in Chapter 32, Hosting, Security, and Compliance). Free includes a small monthly allowance of credits — Make's billing unit, one for each standard module run — and limits how frequently scheduled scenarios can run. (You will also see the older word operations in run logs; since a 2025 pricing change it counts module runs as a metric rather than metering your bill, at one credit per standard operation.)
n8n comes in two forms, as Chapter 2 explained: n8n Cloud, a hosted service with a free trial, and the self-hosted Community Edition, which is free to run on your own machine or server. For week one, take the Cloud trial: sign up at n8n.io, and you get a hosted workspace with none of the server setup. Self-hosting is a genuinely good option later — Chapter 32 covers it properly — but installing software is a different project from learning an editor, and mixing the two on day one doubles your ways to get stuck. One practical note: the Cloud trial runs on a clock and on a capped number of executions, and the trial workspace goes away if you let it lapse — so do this chapter's n8n work early in the window, export anything you want to keep, and be ready to spin up the Community Edition if you outlast the trial.
Verify each account's email confirmation, and skip or dismiss the onboarding wizards for now — all three products will offer to build something for you with templates or AI assistance. Those assistants are real and useful (Chapter 22, Copilots, evaluates them), but they defeat the purpose of this chapter, which is learning where things are by putting them there yourself.
A sandbox is a set of places your experiments are allowed to touch — and, by exclusion, a wall around everything they are not. Automation platforms will cheerfully act on real business data with real consequences from the very first test click, so build the wall before you build anything else:
Automation Sandbox — safe to delete. Give the first sheet a
header row: Name, Email, Note.
Add two or three rows of obviously fake data —
Test Person One, test1@example.com. Fake data
should look fake; a test record named like a real customer will
eventually fool someone, including future you.#automation-sandbox and invite only
yourself. Every test message lands here and nowhere else.That last point deserves its own warning, because it is the least obvious risk in the room.
Watch out: When you "connect" an app to an automation platform, you are usually granting account-level access, not per-workflow access. Connect your Google account to test one spreadsheet and the platform typically holds credentials that can reach every spreadsheet that account can see. The wall, therefore, is behavioral as much as technical: connect low-stakes accounts, scope permissions where the app allows it, and treat every connection as a standing key. Chapter 7 (Connections and Credentials) covers how each platform stores and shares these keys, and Chapter 29 covers governing them in a team.
Finally, adopt a naming convention now, while you have three
workflows to your name instead of three hundred. A workable week-one
pattern: a status prefix and a plain description —
[SANDBOX] Sheet row to Slack. All three platforms sort and
search by name, and future-you will be grateful. Chapter 29 (Teams,
Governance, and Change Management) turns this habit into policy.
Each platform has one central building surface, and each surface teaches you its product's personality faster than any comparison chart. Spend ten minutes in each before building anything. The vocabulary introduced here — bolded on first use — is the vocabulary every later chapter's instructions rely on.
Log in to Zapier and you land on a dashboard with a left sidebar. The
things you build are Zaps — Zapier's word for a
workflow — and they live in the Zaps section of that
sidebar, organized into folders. Start a new one with the
Create button (choose the Zap option; Zapier also offers
Tables, Interfaces, and other surfaces we will meet in Chapter 14 and
Chapter 20).
The Zap editor presents your workflow as a vertical sequence of steps: a trigger at the top, actions below, executing top to bottom. Recent versions render this on a canvas you can pan around, but the mental model remains a list — Zapier's paths feature (Chapter 16, Branching) is the exception, not the rule. Click any step and a configuration panel opens with a consistent rhythm you will come to know well:
Two more locations complete the tour. The publish control (top-right of the editor) is what makes a Zap live — an unpublished Zap does nothing on its own. And Zap history, reachable from the dashboard sidebar, is the run log: every execution — Zapier calls each one a Zap run — with its status, timing, and the data at every step. History is where Chapter 27 (Monitoring, History, and Alerting) and Chapter 28 (Diagnosing Failures) will live; for now, just know where the door is.
Log in to Make and the left rail lists your organization's spaces:
Scenarios, Templates,
Connections, Webhooks,
Data stores, and more. The things you build are
scenarios — Make's word for a workflow — and you create
one from the Scenarios page via the create button.
The Scenario Builder is a genuine canvas: a freeform space where each step is a large circular module, and modules are connected by lines along which data flows left to right. The first module is your trigger; Make marks scheduled triggers with a small clock badge. Click any module to open its settings; click the empty space between or after modules to add new ones from a searchable app list. The wrench icons on connecting lines hide filters — conditions that let data pass or stop it — which we will ignore until Chapter 16.
Three controls define the Make testing experience:
Runs are recorded in the scenario's History tab, one
entry per execution with the full module-by-module detail preserved.
Make also maintains a separate list for incomplete
executions — runs that stopped partway and can be resumed — a
distinctive feature that becomes important in Chapter 19 (Error Handling
by Design).
Log in to your n8n workspace and you land on a list of workflows — n8n uses the plain word. Create one and you arrive at the editor: a canvas in the spirit of Make's, but with rectangular nodes instead of circles, connected left to right.
Add your first node with the + control on the canvas,
which opens the nodes panel — a searchable catalog of
triggers and actions. n8n will prompt you to start with a trigger node,
since a workflow needs one to start on its own. Click any node on the
canvas and it opens in a three-pane detail view that is the heart of the
n8n experience: input data on the left (what arrived
from the previous node), parameters in the middle (this
node's settings), and output on the right (what this
node produced when last executed). Mapping data is literally dragging a
field from the left pane into a parameter in the middle.
The editor has two tabs along the top: Editor and
Executions. The Executions tab is this
workflow's run log — every execution with a full replay of the data at
every node, clickable and inspectable. Two controls on the canvas
complete the set: the test button at the bottom
(labeled along the lines of Test workflow or
Execute workflow depending on version) runs the workflow
once manually so you can watch data move; and the Active
toggle (top-right) is the production on/off switch. n8n draws
the sharpest line of the three between manual test executions —
started by you, shown live on the canvas — and production
executions — started by the trigger while the workflow is
Active.
One n8n-only concept to meet now, because it changes how testing feels: pinned data. After you fetch sample data through a node, you can pin its output (a pin icon in the node's output pane). Pinned data is frozen and reused for every subsequent manual test, so you can rerun your workflow twenty times while tuning a downstream step without re-fetching from the source app each time. Pins apply only to manual test runs — production executions ignore them and fetch live data.
| Concept | Zapier | Make | n8n |
|---|---|---|---|
| A workflow | Zap | Scenario | Workflow |
| One step | Step (trigger/action) | Module | Node |
| One execution | Zap run | Execution (run) | Execution |
| The billing unit | Task | Credit (one per operation) | Execution (self-hosted: none) |
| The building surface | Zap editor | Scenario Builder | Editor canvas |
| Run it once, now | Test step / test Zap | Run once | Test button |
| The on switch | Publish | Scheduling toggle | Active toggle |
| The run log | Zap history | History tab | Executions tab |
Chapter 4's Rosetta Stone maps the deeper conceptual differences; this table is the UI layer of it, and later chapters use these names without re-introduction.
The target, once more: new row in the sandbox Google Sheet → message in the sandbox Slack channel, with the message including the new row's Name and Email. Have your sandbox sheet and channel ready, and log in to Google and Slack in the same browser to smooth the connection prompts.
A word on what you will feel: the three builds are the same automation, and by the third one you will be moving on autopilot. That is the intended effect. The differences you notice along the way — where each product puts the same decision — are the beginnings of your own capability map.
Create and start a new Zap.
You will see an empty trigger step waiting at the top.New Spreadsheet Row).Send Channel Message or similar). Connect your
Slack account — another consent screen, another stored connection.#automation-sandbox
channel. In the message text field, type a template and insert fields
from the trigger where you want live data: click into the field and use
the insert-data control to place Name and
Email from the trigger's sample. Something like:
New signup: + Name + ( + Email +
). This click-to-insert is field mapping
at its simplest — Volume C, Chapter 12 is where it grows up.Watch out: Publishing a Zap means it is on. From this moment, new rows in that sheet will fire it for real — though not instantly. Zapier checks the sheet on a schedule (it polls, in the jargon we unpack at the end of the chapter) rather than the moment a row appears, so expect a delay before a live run happens. If you want to pause between builds, toggle the Zap off from the editor or the Zaps list — off is a state, not a deletion, and your work is preserved.
Scenarios page, create a new scenario. You get
an empty canvas with a single placeholder module.Watch Rows).Limit (the
maximum rows fetched per run) to something small.Name
and Email into your message template, exactly as you typed
text around inserted fields in Zapier.Run once. The
scenario starts listening — and because you chose "from now on," it may
find nothing yet. Switch to your sheet, add a fresh fake row, and watch
the canvas: the modules light up, and numbered bubbles appear above
each.Run once was a manual test;
the toggle is what makes it run without you.Tip: Run once and the scheduling toggle are entirely separate controls, and conflating them is the classic first-week Make mistake in both directions — scenarios left off that were "tested fine," and scenarios left on that were "just a test." Before you walk away from the canvas, look at the toggle and make it say what you mean.
Name and Email from
the input pane on the left directly into the text parameter. n8n renders
each dragged field as an expression token inline with your typed text.
(Those tokens are expressions — a small template language that Chapter
12 covers; today, drag and don't look down.)Each build is now live. Time for the moment this chapter has been walking toward: a real run, caused by a real event, with your hands off the keyboard.
Add one new row to the sandbox sheet — a fresh fake person, not one the workflows have seen. Then wait, and here patience is a technical requirement: all three builds use a polling trigger, one that checks the sheet on a schedule rather than being notified instantly. Depending on platform and plan, the check interval ranges from about a minute to fifteen; nothing you did is broken during the gap.
Tip: "I added the row and nothing happened" is, in week one, almost never a bug — it is a polling interval. Note the time, wait out one full interval, and only then start troubleshooting. The instant alternative — webhooks, where the source app pushes the event the moment it happens — is Chapter 8 and Chapter 9's territory, and it is the standard fix once delay actually matters.
When the interval passes, three messages arrive in
#automation-sandbox — one per platform, since all three are
watching the same sheet. Now go find the evidence, because the run log
matters more than the message:
Zap history from the
dashboard. There is your Zap run, marked successful. Click it: every
step is listed with the exact data in and data
out — the row as the trigger saw it, the message as Slack
received it.History tab.
There is the execution, with its operation count. Click it and the
canvas replays the run, bubbles and all, exactly as
Run once displayed it live.Executions
tab. There is a production execution — note that it is distinguished
from your earlier manual ones. Click it and the canvas loads that run's
data at every node, and you can confirm it used the live row, not your
pinned sample.Reading a run this way — event in, data through, action out, one inspectable record — is the single most transferable skill in this book. Every debugging session in Chapter 26 and Chapter 28, every monitoring setup in Chapter 27, is an elaboration of what you just did.
One last observation before you leave the sandbox running or switch it off (either is fine — off preserves everything). You watched each platform process the new row and only the new row, even though the sheet contains older fake rows. Each trigger keeps track of what it has already seen — a bookmark called deduplication state — and that quiet bookkeeping is why automations do not reprocess history every time they wake. Chapter 8 explains how each platform does it and how it occasionally surprises you.
Take stock of what week one produced. You have working accounts on all three platforms and a sandbox that keeps experiments harmless. You can find and name the load-bearing parts of each builder: the Zap editor's vertical steps, test panels, publish control, and Zap history; Make's canvas, modules, Run once, bundle bubbles, scheduling toggle, and History; n8n's canvas, nodes panel, three-pane node view, pinned data, test button, Active toggle, and Executions tab. And you have shipped the same automation three times, which means the differences between the products are no longer claims in a comparison table — they are things your hands know.
Volume B takes each ingredient you just used on faith and opens it up: what the app catalogs actually contain and how to read them (Chapter 6), what those connections you created really are and how to manage them safely (Chapter 7), the full taxonomy of triggers including the instant kind (Chapter 8), and what to do when the catalog doesn't have your app at all (Chapters 9 and 10). The sandbox stays. You will be gladder of it with every chapter.