Make, formerly Integromat, is a visual automation platform for connecting the apps a business already runs and moving data between them. You build workflows, called scenarios, by dragging modules onto a canvas and drawing the connections between them.
Its real strength is not connecting two apps. Most tools do that. Make earns its place when a workflow has several possible outcomes and someone needs to see all of them at once: an order that routes differently depending on value, a support message that escalates only under certain conditions, a nightly sync that must retry cleanly when one record fails.
The trade-off is honest and worth stating early. That same flexibility means Make asks more of you than a simple trigger-action tool. Expect to spend real time learning how routers, iterators, and error handlers fit together before your first serious workflow runs reliably.
Consider Make if your automations keep hitting the ceiling of “when X happens, do Y” and you need branching, bulk data handling, or conditional logic without writing and maintaining custom code. Look elsewhere if you need one or two straightforward automations and want to be finished this afternoon.
Make at a Glance
What Problem Does Make Solve?
Most automation starts simply. A form submission creates a CRM record. A new invoice posts to accounting. One trigger, one action, done in ten minutes.
The trouble begins when reality intrudes.
Picture a retailer selling through three channels: its own storefront, a marketplace, and a wholesale portal. Each channel formats orders differently. Each order needs to reach the warehouse, post to accounting, and be checked for delivery risk. And the correct response to a delayed shipment is not one thing. It depends on the carrier, the order value, and whether that customer already has an open support ticket.
A linear automation cannot express this. You would need a separate automation per channel, per carrier, per value threshold, and they would drift out of sync the moment someone changed one and forgot the others.
This is the gap Make fills. Real business workflows involve conditional branching, bulk records inside a single event, data that must be reshaped between systems, exceptions requiring a human, failures needing a retry rather than a silent stop, and a mix of scheduled and real-time triggers. Make is built to hold all of that on one canvas where you can see the whole shape of the logic.
How Make Works
The concepts below are the vocabulary you need. Each answers the same three questions: what it is, why it matters, and when you would reach for it.
Scenarios
A scenario is one complete workflow, laid out visually from trigger to final action. Everything else lives inside a scenario.
Why it matters: because the logic is spatial rather than a numbered list, someone who did not build the workflow can look at it six months later and follow what happens. That auditability is underrated until you inherit an automation nobody documented.
Modules
Each node on the canvas is a module: a single action in a connected app. Create a record, send a message, fetch a file, update a row. The first module is usually the trigger that starts the scenario.
Routers
A router splits one flow into multiple paths. Each path carries its own conditions, and paths can run in parallel or diverge permanently.
Why it matters: this is Make’s defining feature relative to simpler tools. Instead of duplicating a workflow for every variation, you express the variations as branches of a single scenario. One place to update, one place to audit.
Filters and Conditions
Filters sit on the connection between two modules and decide whether data passes. A router chooses which path; a filter decides whether this particular record continues down that path at all.
Use them when you want a branch to run only for orders above a threshold, or only for customers in a particular region, without building a separate scenario.
Iterators
An iterator takes an array, a list of things bundled inside one record, and splits it so each entry flows through the following modules individually.
Why it matters: a single order containing five products arrives as one item with a nested list. Without an iterator you cannot check stock on each product separately.
Aggregators
An aggregator does the reverse: it collects processed items back into one array or document.
Together, iterators and aggregators are how Make handles bulk and nested data without a script.
Functions and Data Transformation
Make includes a library of functions for reshaping data inline: formatting dates, parsing text, doing arithmetic, applying conditional logic, mapping one system’s field names onto another’s.
Why it matters: two systems almost never agree on data shape. One expects a date as 2026-08-21, another as 21/08/2026. Transformation happens in the field itself rather than as a separate scripting step.
Webhooks
A webhook gives your scenario a URL that external services can call, starting the workflow the instant an event occurs.
Use webhooks when latency matters: an abandoned cart, a payment failure, a support escalation. Anything where a fifteen-minute delay changes the outcome.
Scheduling
Scenarios can also run on a fixed schedule, from frequent intervals to once daily.
Scheduling suits batch work: a nightly inventory reconciliation, a weekly report. It is also gentler on usage than a scenario that polls constantly.
HTTP and API Connectivity
When no pre-built connector exists, Make’s generic HTTP module can call most modern APIs directly.
Why it matters: a missing connector is rarely a hard blocker. This considerably widens what Make can reach, though calling a raw API does require reading that service’s documentation.
Data Stores
Make provides a lightweight built-in database a scenario can read from and write to between runs.
Use it for simple state: remembering which order IDs were already processed so a re-run does not duplicate work. It is not a replacement for a real database, and it should not become one.
Error Handling
Error handlers attach to individual modules and define what happens when a step fails: retry, take an alternate path, or notify someone.
Why it matters
Iterator and Aggregator: A Worked Example
Checked for stock, tax, warehouse formatting
Checked for stock, tax, warehouse formatting
Checked for stock, tax, warehouse formatting
Each product gets its own stock check and tax treatment, then the aggregator assembles one clean fulfillment request for the warehouse.
The same pattern applies well beyond ecommerce: spreadsheet rows processed individually then summarised, bulk CRM records updated one at a time, or nested API responses flattened into something a downstream system accepts.
Where AI Agents Fit
Make has added AI capabilities that let a scenario call a language model as one step among many. Because this area is evolving quickly, confirm the current feature set and model options on Make’s own documentation before planning around specifics.
Realistically, AI inside an automation platform is good at a defined set of jobs:
- Classification. Deciding whether an inbound message is a refund request, a shipping question, or a complaint.
- Extraction. Pulling structured fields, an order number, a date, an address, out of unstructured text.
- Summarization. Condensing a long email thread before it reaches a human.
- Enrichment. Adding context or categorisation to a record.
- Drafting. Preparing a reply that a person reviews before it sends.
- Routing. Feeding the AI’s output into a router so the workflow branches on what the model determined.
The important framing: AI here is a component inside a workflow, not the workflow itself, and not a customer-facing product.
Note what the diagram does not show: the AI approving anything on its own. The confidence threshold and the routing rule are yours, defined outside the model. Uncertainty should produce a handoff, not a guess.
This is also the honest line between two different things. AI-assisted workflow automation means a model helping decide what happens next inside your internal process. A conversational AI platform means a system holding an actual customer-facing dialogue, with its own knowledge base and escalation design. Make does the first well. Businesses needing the second typically run a dedicated product for it, with Make orchestrating the data movement behind the scenes. Zipprr’s AI Chat sits in that second category, and the division is architectural rather than competitive: the automation platform routes and integrates; the conversational product talks to customers.
Illustrative Case Study: Multi-Brand Ecommerce Order Automation
This is an illustrative scenario, not an account of a specific Make customer. It is constructed to show how the platform’s features combine in a realistic operational workflow. No figures, outcomes, or results below are measured; they describe how the workflow would function.
A mid-sized retailer sells across three channels: its own storefront, a large marketplace, and a wholesale portal for trade buyers. Order volume is steady rather than enormous, but the operational complexity is real, because each channel has different data formats, different fulfilment expectations, and different customers.
The team’s problem is not order entry. It is everything downstream: making sure each order reaches the warehouse correctly, posts to accounting, and gets flagged when delivery looks likely to slip, without a person checking every order manually.
The Workflow
A new order from any channel starts the scenario. The first module normalises it, mapping each channel’s field names onto one internal shape so nothing downstream needs to know where the order came from.
A router then splits the flow three ways:
Fulfilment path. Checks stock and creates a warehouse request. Where an order contains multiple products, this is where the iterator and aggregator pattern from earlier applies.
Accounting path. Posts the transaction to the accounting system with correct tax treatment per channel, since wholesale and retail are handled differently.
Shipping-risk path. The interesting one. It checks the assigned carrier and estimated delivery window against the promise made at checkout.
If no risk is detected, that branch ends quietly. Most orders take this route, and that is the point: the workflow’s job is to surface the exceptions, not to generate noise about everything working normally.
If risk is detected, the scenario evaluates two further things: the order’s value, and whether that customer already has an open support ticket. Both matter. A low-value order to a customer with no history can receive a polite automated notice. A high-value order, or one from someone already mid-conversation with support, should not get an automated message that ignores the context of that conversation. Those route to a human.
Architecture Walkthrough
Reading the branches: normalisation removes channel differences so a single set of rules applies afterward. The three router paths run in parallel because none depends on the others finishing. The nested condition inside the shipping-risk path is where the business judgment lives, and it is deliberately conservative, defaulting to human review when the situation carries more risk than a template message can handle.
A Practical Formula Example
Data transformation happens inline using Make’s expression syntax. Here is an illustrative example that applies a prefix to marketplace order IDs so they remain distinguishable in the warehouse system:
Illustrative example, verify current syntax in Make’s documentation:
{{if(3.channel = “marketplace”; “MP-” + 3.order_id; 3.order_id)}}
In plain English: look at the channel field from module 3; if it says “marketplace”, return the order ID with MP- in front of it; otherwise return the order ID unchanged. One expression, typed directly into the field, no separate scripting step.
Potential Business Impact
No measured results are claimed here. What this workflow could plausibly change, and what a team should measure if they built it:
- Routine order processing moves into automated branches, so staff attention concentrates on genuine exceptions rather than confirming that normal orders are normal.
- Channel-specific handling becomes consistent, because one normalisation step replaces three sets of manual habits.
- Delivery problems surface before the customer complains, rather than after.
- Escalation becomes rule-based instead of dependent on who happens to notice.
Whether those translate into meaningful time or cost savings depends entirely on the business’s volume, current process, and how well the branching rules match reality. Measure the baseline before building, not after.
What the Case Study Demonstrates
The scenario is a reasonable argument for Make specifically, because it exercises the things Make does better than simpler tools:
- Visual branching, so all three paths and the nested risk logic sit on one readable canvas.
- Conditional routing on real business rules: value thresholds, ticket status, carrier performance.
- Data transformation, normalising three channel formats into one internal shape.
- Bulk processing of multi-item orders through the iterator and aggregator pattern.
- API connectivity for the channel or carrier systems lacking a native connector.
- Real-time triggers, because a delivery risk detected tomorrow morning is not useful.
- Error handling, so a carrier API timeout retries rather than silently dropping an order.
- Human-in-the-loop design, keeping judgment calls with people while automating the routine majority.
A tool without native branching could do parts of this, spread across several disconnected automations. Keeping it in one auditable scenario is the argument for Make.
Strengths
Visual workflow design. Complex logic is visible rather than buried in configuration. The practical benefit is handover: a workflow one person built can be understood, debugged, and modified by another.
Complex branching. Routers and filters express real business rules without duplicating workflows. You maintain one scenario instead of six near-identical ones drifting apart.
Data handling. The iterator and aggregator pattern, combined with the function library, covers most reshaping needs that would otherwise require code.
API flexibility. The HTTP module means a missing connector rarely blocks a project outright.
Broad integrations. A large catalogue of pre-built connectors covers common business software, so most scenarios start from working modules rather than raw API calls.
Error handling. Module-level handlers with retries and fallback paths let you build workflows that degrade gracefully instead of stopping dead.
Reusable scenarios and templates. Cloning a working scenario as a starting point matters for teams running similar workflows across brands or regions.
Workflow visibility. Execution history shows what actually ran and what each module received, which is where most debugging genuinely happens.
Limitations
Learning curve. Routers, iterators, and aggregators take time to internalise. Expect a real ramp-up before your first production-grade scenario, not an afternoon.
Scenario complexity. A large scenario with many branches can become hard to read, the very problem the visual canvas is meant to solve. This is manageable with disciplined naming and documentation, and unmanageable without it.
Debugging. Tracing why a specific run took an unexpected branch means working through execution history step by step. Better than opaque alternatives, still slower than reading a stack trace.
Cost model. Because pricing is tied to operations or credits rather than seats, a scenario that seemed inexpensive in testing can consume far more in production if it runs more often than expected or processes larger arrays. Model your volume before committing.
Cost predictability at scale. High-volume workflows require active monitoring. Per-operation billing is fair but demands more attention than a flat fee.
Maintenance. Automations are not set-and-forget. APIs change, business rules change, and someone must own each scenario.
AI limitations. Make’s AI features are useful inside a workflow but are not a substitute for a purpose-built AI product with its own knowledge management and escalation handling.
Governance at larger organisations. Teams needing detailed role-based permissions, audit trails, or environment separation should evaluate current capabilities carefully against requirements rather than assuming enterprise-grade governance.
Capability Scorecard
These are editorial judgments from reviewing the platform’s design and positioning, not benchmark measurements.
| Capability | Score | Comment |
|---|---|---|
| Visual scenario builder | 8/10 | Genuinely clearer than list-based editors for multi-path logic |
| Branching and conditional logic | 9/10 | The strongest reason to choose Make over simpler tools |
| Data transformation | 8/10 | Function library covers most needs without external scripting |
| Bulk data handling | 8/10 | Iterator and aggregator handle nested data well once understood |
| App integrations | 7/10 | Large catalogue, though not the largest available |
| API and webhook flexibility | 8/10 | The HTTP module meaningfully extends reach beyond native connectors |
| AI capabilities | 6/10 | Useful for in-workflow tasks, not a dedicated AI platform |
| Error handling | 7/10 | Capable, but requires deliberate configuration to be effective |
| Collaboration | 7/10 | Reasonable for small and mid-sized teams; larger orgs should verify specifics |
| Learning curve | 6/10 | The cost of the flexibility, scored as friction rather than failing |
Pricing
Make uses tiered subscriptions, typically including a free tier and several paid levels aimed at individuals, small teams, and larger organisations. The distinguishing feature is that pricing is measured in operations or credits consumed rather than by user seat.
An operation generally corresponds to a module execution within a scenario. This has a consequence worth understanding before you buy: cost scales with workflow complexity and run frequency, not team size. A scenario with twelve modules running every fifteen minutes consumes far more than a three-module scenario running daily, regardless of how many people use the platform.
Two practical implications. First, iterators multiply operations, since processing twenty line items individually costs more than handling one record. Second, estimate volume using a realistic scenario design, not a simplified one, before choosing a tier.
Plan names, operation allowances, and prices change. Verify current details on Make’s official pricing page before purchasing.
Make vs Alternatives
Make vs Zapier
Zapier is easier to start with. Its linear model and large connector catalogue make it faster for a non-technical user to build a working automation on day one.
Make is stronger once workflows stop being linear. Native visual branching, iterators, and aggregators handle complexity that would require workarounds or multiple separate automations in a simpler tool.
Choose Zapier when you need many straightforward integrations and want the shortest path to something working. Choose Make when your workflows have conditions, branches, or bulk data, and the extra learning time pays for itself.
Make vs n8n
n8n is also node-based with strong branching, so the comparison is less about capability and more about ownership. n8n is open-source and can be self-hosted, which appeals to teams wanting infrastructure control, specific data residency, or different economics at high volume.
That control has a price: someone must run, update, and secure the infrastructure. Make is fully hosted, with nothing to maintain.
Choose n8n when you have engineering capacity and specific control or cost requirements. Choose Make when you would rather not operate the platform yourself.
Make vs Workato
Workato targets larger enterprise integration, with correspondingly heavier governance, security, and lifecycle-management features. It is a bigger commitment in budget, implementation effort, and organisational process.
Choose Workato when you have enterprise integration requirements, formal governance obligations, and the resources to support them. Choose Make when you want strong automation capability without an enterprise-scale programme around it.
None of these is universally best. The right choice follows from workflow complexity, technical capacity, and governance requirements, in that order.
Security and Compliance
Make publishes security, privacy, and data-handling documentation on its own site. Because certifications and data residency options change over time, verify the current state directly rather than relying on any third-party summary, including this one.
Before adopting Make for anything sensitive, confirm current certification status and scope, data residency and processing locations, encryption practices for data in transit and at rest, sub-processor arrangements, retention and deletion policies, and whatever contractual terms your compliance obligations require.
One point deserves emphasis. Using a platform that holds certifications does not make your workflow compliant. Compliance depends on the whole architecture: which systems the data touches, what is stored where, who has access, and how the workflow itself is designed. Regulated industries, healthcare, financial services, anything under strict data-protection regimes, should evaluate the full data flow with appropriate expertise, not just the automation vendor’s certification page.
Who Should Use Make
Make fits best where workflows are genuinely conditional and the team wants visual control without building software.
Strong candidates include operations teams coordinating processes across several systems; ecommerce businesses handling multi-channel orders, inventory, and fulfilment; agencies managing repeatable client workflows; marketing and RevOps teams connecting CRM, campaign, and reporting tools; and any business running enough SaaS products that keeping them synchronised has become a job in itself.
The common thread is not company size. It is whether your workflows have branches.
Who Should Not Use Make
Make is a poor fit in several situations, and recognising them saves money and frustration.
If you need one or two simple automations, a simpler trigger-action tool will get you there faster with less to learn. If you want the easiest possible beginner experience, the router and iterator concepts will feel like overhead before they feel like power. If nobody will own maintenance, a complex scenario will quietly rot as APIs and business rules change. If you require deep infrastructure control or self-hosting, an open-source alternative fits better. And if what you actually need is a customer-facing conversational AI system, an automation platform is the wrong category, though it may still sit usefully behind one.
Getting Started
A practical sequence, in order:
- Choose one moderately complex workflow. Not the simplest, which teaches you nothing, and not the most critical, which punishes early mistakes.
- Map the business logic on paper first. What are the actual decision points, and what happens on each path?
- Define inputs and outputs explicitly. What data arrives, what must leave, and in what shape.
- Identify branches and exceptions before building. Exceptions discovered mid-build tend to produce awkward retrofits.
- Build the simplest working version first. Get the happy path running before adding conditions.
- Test with realistic data, including the messy records that break assumptions.
- Add error handling deliberately. Decide what should retry, what should reroute, and what should alert a person.
- Review execution history for real runs before switching on broad notifications, so early misconfigurations get caught by a reviewer rather than a flood of alerts.
- Document the scenario while you still remember why each branch exists.
- Assign a named owner. A shared workflow with no owner becomes nobody’s problem until it breaks.
- Monitor usage against a budget in the first weeks, since production frequency often exceeds test expectations.
- Expand one scenario at a time. Migrating every manual process at once reliably goes badly.
What is Make?
Is Make the same as Integromat?
Is Make beginner-friendly?
How is Make priced?
Does Make require coding?
Can Make work with APIs?
Can Make handle real-time workflows?
What are Make's AI capabilities?
Make vs Zapier?
Make vs n8n?
Is Make suitable for enterprise use?
What happens when a scenario fails?
Final Verdict
Make is for teams whose automations have outgrown “when X happens, do Y” and who want to see the resulting complexity rather than scatter it across a dozen disconnected workflows.
Its biggest advantage is visual branching. Routers, filters, iterators, and aggregators let you express real business rules, with all their conditions and exceptions, on a single canvas that someone else can still read next year.
Its biggest drawback is that this capability is not free. The learning curve is real, complex scenarios need maintenance and ownership, and per-operation pricing rewards teams who model their volume before building and punishes those who do not.
Choose something simpler if you need a handful of straightforward integrations. Choose n8n if self-hosting and infrastructure control matter more than convenience. Choose Workato if you have enterprise governance requirements and the programme to support them.
If you sit in the middle, complex enough to need branching, not so large that you need an enterprise integration platform, Make is a strong choice. The practical recommendation: pick one workflow that currently costs your team real time, map its branches on paper before touching the canvas, and build that single scenario properly. You will know within a couple of weeks whether the model fits how your business actually works, and that answer is worth more than any review.
Mapping Your Own Workflow
The hardest part of a project like the one described here is rarely the platform. It is deciding which decisions should be automated, which need a person, and what happens when a step fails.
If you are working through that for your own operation and want a second opinion on the design before you build it, Zipprr works on exactly this kind of workflow mapping and AI integration. Either way, the sequence in the Getting Started section above is the right place to begin: one workflow, mapped on paper, built properly.
