The Make.com “Terminology Rosetta Stone”

One of the challenging things about learning Make is learning their unique set of terminology.

This “Rosetta stone” will help you decipher at a glance some of the special Make.com terminology.

Depending on your dev skills, I’ve included a special list of translations for you below, as Make has definitions for certain dev terms that can be confusing when coming from a typical backend dev background, as they’re often at odds with “dev terminology.” So I’ve attempted to translate them into the typical dev terminology equivalent.

📜 Translations for Everyone

• “Module” — A single building block within Make; each block performs a specific task (e.g., sending data to a spreadsheet, triggering an API call).
• “Operation” — Each instance of a module running in real time. Multiple steps or data points processed in a loop count as individual operations.
  • Example: If a repeater has two modules and runs twice, the total operations are:
    • Repeater x1
    • Module A x2
    • Module B x2
• “Scenario” — A full, standalone automation workflow made up of multiple connected modules and triggers.
• “Data Store” — A built-in, database-like module within Make that stores and retrieves data across scenarios, useful for holding information you need repeatedly without an external database. We don’t typically use these for list-building purposes, in favor of Google Sheets. (You can’t easily export Make’s data stores to a csv 😳)
• “Flow Control” — Modules like “Router” or “Filter” that control the flow of data, allowing different actions based on data inputs or conditions.

🧑‍🎨 Translations for Non-Devs

• Aggregator — Combines items into a list, like putting multiple names into a single contact list.
• Iterator — Processes each item one at a time, often used when you need to “do something” individually for each item (e.g., sending an email to each contact).
• Repeater — Similar to an iterator but runs a set number of times without flexible control over stopping. We won’t typically use these over iterators unless we’re doing fancy batching stuff.
• Filter — A “decision-maker” within the automation that tells Make if the automation chain should keep continuing onwards depending on the rules you set. These are set on the dotted line paths that connect modules.
• Router — A module that splits the workflow into multiple paths, performing different tasks based on conditions. Think of it as a “choose your own adventure” for data, if you need to do different things depending on what happened earlier in an automation chain.

🧑‍💻 Translations for Devs

Make has definitions for certain dev terms that can be confusing when coming from a typical backend dev background, as they’re often at odds with “dev terminology.” So I’ve attempted to translate them into the typical dev terminology equivalent.

• Iterator — Functions like a foreach loop, processing each item in a set one at a time.
• Repeater — A for loop without the ability to break;, running until all items are processed.
• Aggregator — They don’t have a super-great coding parallel, so they’re hard for me to define. An aggregator is a powerful tool for consolidating or restructuring data within Make. Think of it as a way to group, combine, or transform multiple data points into a single output, often resulting in an array or a restructured JSON object. Aggregators are useful for actions like merging rows into a list or creating a new structure by grouping similar items. They’re especially handy because most operations in Make only handle the first item in an array by default, whereas an aggregator allows you to manipulate the data as a whole set.
• Filter — Acts as a where clause, allowing you to set conditional logic based on JSON attributes, custom variables, or module output before continuing on with the automation action chain. These are set on the dotted line paths that connect modules.
• Router — Similar to a switch-case control flow, allowing branching within a single scenario. BUT the crazy thing is that it’s not actually “if/elseif” logic — it will branch into ANY AND ALL paths that are true.
• Data Store — Functions as an embedded, lightweight database where you can perform CRUD (Create, Read, Update, Delete) operations, great for maintaining persistent data across scenario runs. We don’t typically use these for list-building purposes, in favor of Google Sheets. (You can’t easily export Make’s data stores to a csv 😳)
• Error Handler — Make’s method for managing exceptions in workflows. Essential for handling cases where API calls fail or expected data is missing, preventing unexpected process stops.
• HTTP Module — For custom API calls, offering GET, POST, and other HTTP methods to interface with external systems.
• Arrays & Objects — Basically the same as normal code. Arrays are unstructured lists; objects have key/value pairs.
  • NB: Array indexes in Make often start at 1 instead of 0; at least in some cases. IIRC it’s in repeaters, aggregator loops, etc.
• Bundle — Each bundle in Make functions like a single data packet or JSON object, representing an independent “unit” of data that flows through a scenario. Think of each bundle as its own instance with a unique set of key-value pairs, similar to processing one “record” or “row” at a time in a structured sequence.