Make: Visual Automation at a Glance

Make in one sentence

Make is an automation platform where you assemble processes as a scenario — a visual network of modules that can branch, loop through lists, merge data, and react to errors — with no programming, but with far more structure than a simple if-then chain.

The difference from classic no-code services lies exactly in this structure. Where other tools map out a linear process, in Make you draw a flowchart with multiple branches. That makes getting started somewhat more demanding and building convoluted processes noticeably easier.

The scenario concept

Three terms are enough to get started.

Modules

A module is a single building block in the scenario. There are three roles:

• Trigger modules start the scenario — on a schedule, via an incoming call, or when an event occurs in a connected service.
• Action modules execute something: create, update, send, retrieve.
• Search and tool modules fetch records, reshape values, calculate, or control the flow.

Modules are connected by lines, forming not a rigid chain but a network.

Bundles

Every record that flows through the scenario is a bundle. If a module returns ten rows, ten bundles are created — and each one runs individually through the subsequent modules. This bundle logic is the key to understanding Make, because it explains both list behavior and billing.

Routes

A router splits the process into multiple branches that continue in parallel. Each branch gets its own filter and its own modules. This lets you cleanly separate cases: an incoming request moves into different processing depending on its type, without you having to maintain three separate scenarios.

If trigger, action, and logic are still unfamiliar basic concepts to you, start with Workflow Automation: Basics.

Where Make really shines

Four tools explain why Make has the edge with complex processes.

Iterator. Breaks a structure down into individual bundles. An order with twelve line items becomes twelve records, each processed individually afterward. Exactly what linear tools regularly struggle with.

Aggregator. The counterpart: merges many bundles back into one — for example, all the line items into a single text list for a confirmation email, or all of a day's entries into a single report. The combination of iterator and aggregator covers most demanding data tasks.

Per-module error handling. Every module can have its own error path attached: retry, skip, continue with a fallback value, or deliberately abort. That's more finely controllable than a global error rule, and it's why Make scenarios often run more stably over the long haul.

Data stores and temporary storage. Make comes with its own storage where a scenario can persist state across runs — for example, to remember which records have already been processed. Without this, many processes turn into a workaround.

On top of that comes the visual benefit: a scenario with fifteen modules and three routes stays readable as a diagram. The same logic as a long list of steps is not.

The pricing model: operations, not tasks

Make bills by operations — roughly speaking, an operation is one module processing one bundle. The difference from billing by actions matters:

• A scenario with four modules and a single record costs four operations.
• The same scenario with ten records doesn't cost four, but many times more — because every module processes every bundle individually.
• Search, filter, and tool modules consume operations too, not just the writing actions.

That gives you three planning rules:

1. Filter early. The sooner unnecessary bundles are eliminated, the fewer modules touch them.
2. Aggregate before you write. Writing ten bundles individually to a target system is more expensive than combining them first.
3. Check the trigger interval. A scenario that runs empty every few minutes still consumes operations. For rare events, a longer interval or an event-based trigger is the cheaper choice.

The pricing structure follows a tiered pattern: a free tier with a small operation allowance and a limited execution frequency, then paid plans above it with more operations, shorter intervals, and additional features like data stores, custom connections, and finally team and enterprise features with permission management. Unlike with some competitors, multi-step processes and branches are not hidden behind a higher pricing tier — that's one of the reasons Make is attractive for more complex use cases from the start.

A scenario step by step

Using the example "capture incoming invoices and submit them for approval":

1. Choose the trigger. A mail module watches a shared inbox and starts the scenario on new messages with an attachment.
2. Split the attachments. An iterator turns an email with three attachments into three bundles that continue individually.
3. Filter. A filter lets only PDF files through. Everything else ends here — and doesn't consume any further operations.
4. Read the content. A module extracts the text from the document. For invoice number, amount, date, and vendor, an AI step follows that maps the values into a fixed field schema. Why the output absolutely must be validated against a schema is explained in AI Automation.
5. Check plausibility. Another filter catches obvious errors: missing amount, impossible date, empty vendor. These cases go into a review folder instead of accounting.
6. Use a router. Branch one writes the record to the accounting table. Branch two saves the renamed file in the cloud folder. Branch three creates an approval task for amounts above a threshold.
7. Aggregate and report. At the end, an aggregator combines all the invoices processed from one email into a single summary message — instead of sending three separate notifications.
8. Attach error paths. Each writing module gets its own error path with a retry and an alert to a real person if that also fails.

Notice the structure: filter early, scope the AI narrowly, summarize late. This exact order keeps a scenario both affordable and stable.

Strengths and limits

Make is strong with nested data structures, multi-step processes with branches, fine-grained error handling, and anywhere a process needs to stay visually traceable. AI steps can also be cleanly integrated — from model calls to knowledge retrieval.

Limits show up at the entry barrier: anyone who just wants to connect two tools gets there faster with a more guided tool. The number of ready-made integrations is lower than the market leader's. And at very high volumes, per-operation billing becomes noticeable, because every module counts every bundle individually. Where the alternatives fit better is clarified by n8n vs. Zapier vs. Make — a look at Zapier is worthwhile especially for its larger selection of integrations.

Conclusion

Make is the right choice when your processes need to branch, work through lists, and respond to errors in a differentiated way. Iterator, aggregator, router, and per-module error paths cover requirements that simpler tools fail at — and the scenario stays readable as a diagram throughout. Anyone who understands the operations logic, filters early, and aggregates late keeps the costs predictable.