Skip to content

AI Automation with n8n, Make and Zapier · Make in depth · lesson 5 of 17 · 16 min

Make scenarios: modules, routers, iterators and data stores

How Make thinks

Make (formerly Integromat) builds automations as scenarios: a visual chain of modules, where each module is an app action or a tool. Data flows as bundles (one record each). Make's strength is visual, fine-grained control over data: you can split, filter, route, transform and aggregate with precision, without code.

Billing is in credits: since August 2025, Make replaced "operations" with credits (standard module runs consume one credit each; AI features can consume credits based on usage; some modules such as routers and error handlers do not consume credits). Plans and costs change; check the current pricing and credits documentation.

Scenario anatomy

| Element | Purpose | |---|---| | Trigger module | Instant (webhook) or polling (checks on a schedule) | | Action / search modules | Create, update, get, list records in apps | | Router | Split into multiple routes; each route can have a filter | | Filter | Condition between modules; bundles that fail stop on that route | | Iterator | Turn an array into separate bundles | | Aggregator | Combine bundles into one (array, text, numeric, table) | | Tools | Set variable, Get variable, Sleep, Repeater, Increment, Switch | | HTTP module | Call any API ("Make a request"), including OAuth and API keys via connections | | Webhooks | Custom webhook trigger; Webhook response module | | Data stores | Built-in simple database tables for state (dedupe keys, counters, lookups) | | Data structures | Define JSON schemas for parsing and generating JSON |

Mapping and functions

Click a field and map values from earlier modules (shown as numbered bubbles, for example 1.email). Make's formula language offers functions for text (lower, trim, replace, substring), dates (formatDate, parseDate, addDays, now), math, arrays (map, get, join, length) and logic (if, ifempty, switch). Function arguments are separated by semicolons.

{{lower(trim(1.email))}}
{{ifempty(1.company; "Unknown")}}
{{formatDate(addDays(now; 1); "YYYY-MM-DD"; "Asia/Karachi")}}
{{join(map(2.line_items; "sku"); ", ")}}

Scheduling and execution

  • Scenarios run on schedule (every N minutes, daily at a time, specific days), immediately for instant triggers, or on demand.
  • Sequential processing option handles bundles in order (useful when order matters or APIs are rate-limited).
  • Incomplete executions can store failed runs for later resolution (when enabled with appropriate error handling).
  • The execution history shows each run with bundle data per module for debugging.

Error handlers (preview; detail in Module 6)

Attach an error handler route to a module: Resume (substitute output and continue), Ignore (skip this bundle), Break (store as incomplete execution and optionally retry automatically), Commit and Rollback (for transactional modules). Use them deliberately instead of letting scenarios stop.

Worked example: a Lahore e-commerce order-to-fulfillment scenario

Trigger: Shopify "Watch Orders" (instant). Router with three routes:

  1. Filter: payment method = COD -> create a COD verification task in Google Sheets and send a WhatsApp template asking the customer to confirm.
  2. Filter: total > PKR 50,000 -> Slack alert to the owner.
  3. All orders -> Iterator over line items -> search inventory sheet -> Aggregator builds a picking list text -> email to the warehouse.

A data store records processed order IDs so that if the scenario is re-run, orders are not processed twice.

Hands-on: build a lead-intake scenario

  1. Webhooks > Custom webhook: create, copy the URL, send a sample payload so Make learns the structure.
  2. Tools > Set multiple variables: email = {{lower(trim(1.email))}}, phone = {{replace(1.phone; "/[^0-9+]/g"; "")}}.
  3. Data store > Search records by email (dedupe). Add a filter: continue only if not found.
  4. Router: Route A (filter 1.country = "AE" or "SA") assigns the Gulf team; Route B (filter 1.country = "PK") assigns the Pakistan team.
  5. On each route: CRM > Create a contact and Slack > Create a message.
  6. Data store > Add/replace a record with the email key.
  7. Webhook response: status 200, body {"ok": true}.

Run once with sample data, inspect bundles in each module, then enable scheduling.

Pitfalls

  • Polling triggers every minute for rarely changing data, consuming credits needlessly.
  • Forgetting that each bundle from an iterator multiplies downstream module runs (and credits).
  • No dedupe store, so re-runs create duplicate records.

Measuring success

Track credits per successful outcome (per lead, per order), execution errors per week, and how often incomplete executions need manual resolution. A well-designed scenario uses few credits per outcome and rarely needs a human to intervene.

Video lecture: Make scenarios: modules, routers, iterators and data stores

Lecture coming soon · 13 chapters · about 9 minutes. Read the full transcript below.

  1. Make scenarios
  2. Lesson roadmap
  3. Why Make
  4. Analogy: a sorting office
  5. Scenario anatomy
  6. Mapping and functions
  7. Credits (since Aug 2025)
  8. Example 1: lead intake
  9. Example 2: Lahore order flow (illustrative)
  10. Common mistakes
  11. Watch me do it: intake scenario in Make
  12. Recap + try this now
  13. Try this now

Lecture transcript

Make scenarios

If n8n feels like programming with boxes, Make feels like drawing with data. Its visual builder gives you fine-grained control over how records split, filter, route and merge, without writing code. That's why agencies and operations teams love it for complex data work. In this lesson, you'll learn how Make thinks in scenarios, modules and bundles, the key tools like routers, iterators, aggregators and data stores, the formula language, and how credits work. Then we'll build two real scenarios.

Lesson roadmap

A quick orientation before we dive in. In this lesson you'll first get the mental model, then the building blocks, then the formula language and billing, and finally two builds: a simple lead intake and a realistic order flow for an online store in Lahore. If you've used n8n or Zapier, you'll notice the concepts are the same. What changes is how visually Make shows each record moving through the scenario.

Why Make

Why does this matter? Because most business automations aren't hard because of the apps. They're hard because of the data: orders with many line items, leads arriving in different formats, reports that need totals. Make lets you see every record moving through every step, which makes complex data work visible and debuggable. If your automation needs to split, filter, route, transform and summarize, Make is often the fastest way to build it without code.

Analogy: a sorting office

Here's an analogy. Think of a scenario as a sorting office. Each parcel is a bundle, one record. Modules are the workers who open, stamp, forward or store each parcel. A router is a sorting belt with several chutes, and filters are the signs on each chute saying which parcels may enter. An iterator is the worker who opens a box of many items and sends each item down the belt separately. And an aggregator packs items back into one box at the end. Keep that picture in mind and Make's behavior stops being surprising.

Scenario anatomy

Now the anatomy. A trigger module starts things, either instantly through a webhook, or by polling an app on a schedule. Action and search modules create, update and find records. Routers split into routes, and filters sit between modules to decide which bundles pass. Iterators and aggregators split and combine arrays. Tools like set variable, sleep and repeater help with logic. The HTTP module calls any API. Webhooks can both receive and respond. And data stores are simple built-in tables for state, like remembering which order IDs you've already processed.

Mapping and functions

Mapping is where Make shines. Click a field and choose values from earlier modules, shown as numbered bubbles, like one dot email. Wrap them in functions: lower and trim to clean an email, if empty to provide a default like Unknown, format date with add days to produce tomorrow's date in Karachi time, and join with map to list the SKUs from an order. One syntax detail trips everyone up: function arguments are separated by semicolons, not commas.

Credits (since Aug 2025)

A word on billing. Since August twenty twenty-five, Make bills in credits instead of operations. Standard module runs cost one credit each, AI features can cost credits based on usage, and some modules, like routers and error handlers, don't consume credits. Why does that matter for design? Because every bundle an iterator creates multiplies the module runs after it. An order with twenty line items, going through five modules, is a hundred runs. Design with that multiplication in mind, and check current pricing pages.

Example 1: lead intake

Example one, simple. A lead-intake scenario. A custom webhook receives form data. A set-variables module cleans the email and phone. A data store search checks whether this email already exists, and a filter stops duplicates. A router sends Gulf leads to one team and Pakistan leads to another, each route creating a CRM contact and posting to Slack. Finally, the email is stored in the data store and the webhook responds with ok true. Seven modules, clear and debuggable.

Example 2: Lahore order flow (illustrative)

Example two, realistic. A Lahore e-commerce store watches Shopify orders instantly. A router has three routes. Cash-on-delivery orders create a verification task and send a WhatsApp template asking the customer to confirm, which reduces fake orders. Orders over fifty thousand rupees alert the owner in Slack. And every order goes through an iterator over line items, a search of the inventory sheet, and an aggregator that builds a picking list emailed to the warehouse. A data store of processed order IDs means re-runs never double-process an order.

Common mistakes

Three mistakes cost Make users the most. First, polling every minute for data that rarely changes, burning credits for nothing. Use instant triggers or a sensible schedule. Second, forgetting iterator multiplication, so a scenario that looked cheap in testing becomes expensive with real orders. Third, no deduplication, so re-running a scenario creates duplicate records. A data store keyed by a unique ID fixes that. And a bonus: letting scenarios stop on errors instead of attaching error handlers, which we'll cover in module six.

Watch me do it: intake scenario in Make

Watch me do it. I rebuild our lead intake in Make. New scenario, named sales lead intake webform version one. I add a custom webhook, copy its URL, and send the same messy sample payload so Make learns the structure. Next, set multiple variables: email equals lower of trim of one dot email; phone uses a replace formula to strip everything except digits and plus, and a second step adds the country code when missing. I notice I've typed a comma inside ifempty, and the formula errors. Semicolons, not commas. Fixed. Then a data store called processed leads, keyed by email. A search records module looks up the email, and a filter lets only not-found bundles continue. Then a router with three routes: Pakistan to the Lahore team, UAE or Saudi Arabia to the Dubai team, and a fallback route to the default owner. Each route creates the CRM contact and posts to Slack. After the router, an add a record module stores the email. Finally a webhook response returns status two hundred. I run three tests: a Pakistani lead, a Dubai lead, and the Pakistani lead again. The execution history shows the third one stopped at the filter, and the credits counter shows exactly how many module runs each test used.

Recap + try this now

Recap. Make scenarios move bundles through modules. Routers and filters decide paths, iterators and aggregators split and combine arrays, data stores remember state, and formulas transform data, with semicolons between arguments. Credits scale with module runs, so design for multiplication. Try this now: build the lead-intake scenario from the lesson text. Send three test submissions, including one duplicate, and check in the execution history that the duplicate stopped at the filter.

Try this now

Try this now, in detail. Create a new scenario and add a custom webhook. Send one sample submission so Make learns the structure. Add set multiple variables to clean the email and phone. Create a data store with email as the key, and add a search plus a filter so only new emails continue. Add a router with Gulf and Pakistan routes, each creating a CRM contact and a Slack message. Store the email in the data store, add a webhook response, then send three test submissions, including one duplicate.

Key takeaways

  • Make scenarios pass bundles through modules; routers with filters branch, iterators split arrays, aggregators combine them.
  • Make formulas map and transform data (lower, trim, ifempty, formatDate, map, join) with semicolon-separated arguments.
  • Since August 2025 Make bills in credits; iterators multiply downstream module runs, so design for volume.
  • Use data stores for dedupe and state, and attach error handlers rather than letting scenarios stop.

Try it

Build the seven-step lead-intake scenario. Send three test submissions including a duplicate and confirm in the execution history that the duplicate stopped at the filter.