Make is a cloud-based, visual automation platform in which users build workflows called scenarios by connecting modules for applications, data transformations and control logic on a drag-and-drop canvas. Known as Integromat until its rebranding in 2022, it belongs to the family of automation platforms in the automation domain alongside Zapier, n8n and Power Automate.
Its distinguishing trait is explicit data flow: every module receives and emits discrete packets of data called bundles, and the canvas shows exactly how those bundles branch, loop and merge. This makes Make well suited to multi-step integrations with branching logic, where a simple linear trigger-and-action tool becomes hard to manage.
How a Make scenario processes data
A Make scenario is a directed graph of modules that starts with a trigger and passes bundles from left to right. The trigger module either checks a service for new records on a schedule or receives them instantly through a webhook. Each following module performs one operation on each bundle it receives, such as creating a record, calling an HTTP endpoint or transforming text.
Execution is bundle-oriented rather than run-oriented. If a trigger returns 20 new orders, the downstream modules run 20 times within one execution, once per bundle. This model explains both the power of Make and its main cost driver, because every module run consumes billable units, traditionally counted as operations.
The following table summarizes the building blocks that appear on almost every scenario canvas.
| Element | Role in the scenario | Typical use |
|---|---|---|
| Trigger | Starts an execution and emits bundles | Watch new rows, receive a webhook |
| Action module | Reads or writes data in one application | Create invoice, update contact |
| Router | Splits the flow into parallel routes | Different handling per order type |
| Filter | Lets a bundle pass only if conditions hold | Continue only when amount exceeds a limit |
| Iterator | Turns one array into many bundles | Process each line item separately |
| Aggregator | Merges many bundles into one | Build one summary email or CSV file |
| Error handler | Defines what happens when a module fails | Retry later, skip or roll back |
Triggers, scheduling and execution limits
Make offers two trigger styles with different latency and cost profiles. Polling triggers run on a schedule and ask the source application for changes, while instant triggers rely on a webhook that the source calls when an event occurs. Polling consumes operations even when nothing new exists, so instant triggers are cheaper and faster wherever the source supports them.
Scheduling and runtime are bounded by plan and platform limits. The table lists the parameters that most often shape scenario design; exact values change between plan tiers and over time, so they should be confirmed in the current account settings.
| Parameter | Typical range or behavior | What it affects |
|---|---|---|
| Minimum schedule interval | About 15 minutes on free tiers, down to 1 minute on paid tiers | Latency of polling scenarios |
| Maximum execution time | Roughly 40 minutes per execution on standard plans | Large batch jobs must be split |
| Maximum bundles per poll | Configurable per trigger, often 1 to several hundred | Throughput versus operation use |
| Webhook queue | Incoming requests are queued and processed in order | Burst handling and ordering |
| Data transfer and file size | Capped per plan | Handling of attachments and media |
Scenarios run sequentially by default, which preserves order but limits throughput. Enabling parallel processing of webhooks increases speed but removes ordering guarantees, a trade-off that matters for financial or inventory data.
How Make compares with other automation platforms
Make occupies the middle ground between linear no-code tools and developer-oriented workflow engines. Compared with Zapier, it exposes more control over data structures, arrays and error paths. Compared with n8n, it is a fully hosted service without a self-hosting option. Compared with Airflow, it targets application integration rather than scheduled data pipelines.
| Platform | Primary strength | Hosting model | Typical user |
|---|---|---|---|
| Make | Visual branching and array handling | Vendor cloud only | Operations and integration specialists |
| Zapier | Breadth of app catalog and simplicity | Vendor cloud only | Business users |
| n8n | Code-friendly nodes and self-hosting | Cloud or self-hosted | Technical teams |
| Power Automate | Microsoft 365 and desktop RPA integration | Microsoft cloud plus desktop agents | Microsoft-centric enterprises |
| Airflow | Code-defined batch pipelines | Self-hosted or managed | Data engineers |
| Node-RED | Event flows for devices and protocols | Self-hosted, often on edge hardware | IoT and industrial developers |
The choice usually depends on data sovereignty, complexity and team skills. Make fits teams that need complex logic without writing code but can accept that workflow data passes through a third-party cloud.
Designing reliable scenarios in Make
Reliable scenarios rely on explicit error handling rather than on default behavior. When a module fails without a handler, the execution stops and, if enabled, is stored as an incomplete execution that can be resolved and resumed later. Attaching an error route to risky modules gives control over the outcome.
| Directive | Effect | Suitable situation |
|---|---|---|
| Ignore | Drops the failed bundle and continues | Non-critical enrichment steps |
| Resume | Substitutes a fallback output and continues | Missing optional values |
| Break | Stores the execution for retry later | Temporary outages and rate limits |
| Commit | Stops and keeps completed changes | Partial success is acceptable |
| Rollback | Stops and reverts supported transactional steps | All-or-nothing database writes |
Further good practices include idempotent write steps, such as searching for an existing record before creating one, and storing external identifiers in data stores to prevent duplicates. Naming modules, adding notes and keeping scenarios small make maintenance by other team members realistic.
Limitations and common mistakes
The most frequent problem is unexpected consumption of operations. A polling trigger every minute, an iterator over large arrays or a missing filter early in the flow can multiply usage far beyond estimates. Placing filters immediately after the trigger and preferring webhooks keeps usage predictable.
- Ignoring array structure: mapping an array field into a single-value field silently uses only the first item.
- No error routes: a single API timeout stops the whole execution and may leave data half-written.
- Hidden coupling: scenarios that call each other through webhooks become difficult to trace and version.
- Vendor lock-in: scenario logic is stored in a proprietary format, so migration means rebuilding, not exporting.
- Compliance gaps: personal data processed in scenarios requires a review of data residency and retention settings.
In simple terms
Make is a tool that lets different online services work together without anyone writing code. You draw a chain of boxes on the screen, and each box does one job: read an email, save a file, send a message. Data travels from box to box like parcels on a conveyor belt, and you can add switches that send each parcel down a different path.
The key point is that Make does repetitive digital chores automatically and visibly. Anyone who opens the scenario can see where each piece of information comes from and where it goes.
A practical example
A small online shop receives about 150 orders a day through its store platform. The operations manager builds a Make scenario with an instant webhook trigger for new orders. A router sends domestic orders to the shipping service and international orders to a customs documentation step, while a filter flags orders above 500 dollars for manual fraud review.
An iterator splits each order into line items to update stock in a spreadsheet, and an aggregator sends one daily summary to the finance team. A Break error handler on the shipping module stores failed executions during carrier outages and retries them automatically. The result is that order handling time drops from about two hours of manual work per day to a few minutes of exception review.