Make Automation Guide: Features, Setup and Trade-Offs
See how Make compares with linear automation tools, what its routers and data tools do, and how to build a safer lead workflow. Start with a practical plan.
Make Automation: From Integromat to a Practical Workflow Tool
A form submission comes in. Someone copies the details into a CRM, checks whether the company is a good fit, then pings sales in Slack. None of those steps is hard - but the same tiny handoff happens again and again, and eventually you start relying on memory instead of process.
That's the promise of visual automation: build the steps once, then let the workflow handle the repetition. Make (formerly Integromat) connects apps and lets you design workflows on a visual canvas. It's not just a straight trigger-and-action chain. In a Make scenario, you can branch, transform data, process lists, and define what happens when something fails. That flexibility is powerful - but it also means you need a bit more understanding than you would with a simpler tool.
This guide walks through where Make came from, what its features are actually good for, and how to build a lead-qualification workflow without turning a quick prototype into something fragile in production. It also covers the trade-offs to consider before you move from Zapier or write a custom integration. The goal isn't to automate everything. It's to choose a repeatable process where automation saves time without creating a bigger support problem.
Why Integromat Became Make
Make launched in 2012 as Integromat, and it took a different approach to integrations. A lot of early automation tools treated a workflow like a line: when one event happens, do the next step. That works fine for simple tasks. It gets messy when a real process needs conditions, repeated records, or different paths depending on the data.
Take an online order. It can include multiple products, require an inventory update per item, and vary based on the customer or order value. You can stretch a linear chain to cover some cases, but the more complicated the logic gets, the harder it is to inspect later. The core problem isn't that linear tools are "bad." It's that the workflow starts acting like a small program, and the interface has to make that logic visible.
Integromat treated automation like a connected graph. Modules - triggers, actions, and data operations - sit on a workspace and connect into a scenario. That visual structure makes branching and data movement easier to follow than a long sequence of nested steps. Make is the successor to Integromat, rebranded in 2022 after Celonis acquired the platform.
A canvas is useful when it matches the real process
The visual approach isn't just decoration. If your workflow has multiple routes or transformations, a diagram helps you see where the lead enters, what determines its path, and what happens after each decision. And when something breaks, that same map makes it easier to trace execution and inspect the data moving between modules.
That said, a visual canvas doesn't magically make every workflow understandable. A scenario with dozens of modules, unclear names, and overlapping filters can be just as hard to debug as code. You still need structure: name modules clearly, group related logic, and avoid putting too much responsibility into a single scenario.
Make is best thought of as a low-code integration environment, not a universal replacement for custom integrations. It can cut down on code for common business workflows. But you still need to understand the systems you're connecting, how their data is modeled, and what happens when an update fails.
What Make Does Well
Make's biggest advantage is that it gives you building blocks for workflows more complex than "if this, then that." Whether it's worth it depends on the problem: a multi-route CRM workflow can benefit a lot, while a simple notification might be quicker to set up elsewhere.
Routers and filters make branching clearer
A router splits an incoming bundle of data into separate routes. Each route can include its own filter, so you can send an enterprise prospect to a CRM and trigger a sales alert, while a general enquiry goes into an email sequence. You can also define a fallback route for records that don't match the main conditions.
Filters are only as reliable as the data and rules behind them. "Company size is at least 20" sounds straightforward, but it depends on whether your form actually captures a consistent company-size field. A budget threshold won't help if users frequently leave it blank or enter values in mixed formats. Before you add sophisticated routing, decide what should happen when a field is missing, invalid, or ambiguous.
Iterators and aggregators handle lists
Many business apps send arrays - lists of order items, contacts, or rows from a spreadsheet. An iterator takes items from an array and runs the workflow logic on each item one by one. That's useful when each item needs its own action, like updating inventory per product in an order.
An aggregator does the opposite: it takes multiple bundles and combines them into a single output - like a summary message or a structured payload. This can help you avoid sending one notification per line item when a digest makes more sense.
These tools don't remove data-model work. You still need to know whether a field is a single value, an array, or a nested object - and what happens when the array is empty. Test with realistic payloads, including optional fields and different list sizes. A workflow that works on a clean sample can still fail on normal production data.
Error handling gives you real control over failure paths
Third-party services time out, rate-limit requests, and sometimes return responses you didn't expect. Make supports error handlers and directives so you can decide what happens when a module fails. In different situations, you might want to ignore a non-critical error, resume with a fallback value, commit completed work, roll back a transaction, or pause and retry.
Those choices aren't interchangeable. Skipping a failed non-critical CRM update might be acceptable if you log the error and someone can fix it later. Silently ignoring a failed payment or order operation is not. For each important workflow, decide which failures can be handled automatically, which ones require a human, and how the operator will know the workflow needs attention.
Retries also need care. Retrying an operation that creates a record can produce duplicates if the first attempt actually succeeded but the response was lost. Where possible, use idempotency keys, "lookup-before-create," or another deduplication approach. Error handling isn't just about keeping the scenario running - it's about avoiding incorrect side effects when systems behave unpredictably.
Pricing needs to match your actual workload
Automation platforms often meter usage in some way, but plan names, quotas, and billing rules can change. Check Make's current pricing and documentation before you estimate costs. Count expected scenario runs, modules per execution, bundles created by iterators, and any scheduled polling. A workflow that processes one form submission is different from one that expands 100 records into separate operations.
A lower headline price doesn't automatically mean lower total cost. Include the time required to build, monitor, and maintain the workflow, plus any paid plans needed in connected services. The useful comparison is total cost for a workflow that meets your reliability and support needs - not the price per run in isolation.
Build a Lead-Qualification Scenario
Here's an example that takes a website enquiry, cleans a few fields, and routes the lead appropriately. Module names and integrations can change, so use Make's current app directory and documentation when you build this. And treat the first version as a tested prototype, not a production guarantee based on "it took 15 minutes."
1. Start with the trigger and a real sample
Create a new scenario and add a Custom Webhook trigger. Copy the endpoint into your form provider (for example, Webflow, Tally, or Typeform), then submit a test entry. Make needs a sample payload so you can map fields.
Use a test record that looks like a real submission. Include optional fields, a company name, a plausible email address, and the values your routing rules will rely on. If your form can submit different types of enquiries, test each type. A successful sample only proves the workflow can handle that specific payload shape.
2. Normalize data before routing
Add a text or variable operation for cleaning fields that are safe to normalize. For example, trimming whitespace around names can reduce avoidable CRM duplicates. Apply capitalization carefully too - names and company names don't always follow neat title-case patterns.
Validate email syntax, but be careful about blocking free email providers. A Gmail address doesn't automatically mean a lead is low quality, and a company domain doesn't automatically mean it's legitimate. If disposable-email detection matters, use a dedicated validation service or an explicit business rule. Also decide what happens when the result is uncertain - don't just discard "maybe" leads without a plan.
3. Add routes and define fallback behavior
Add a Router and create a qualified-lead route with filters based on fields your form reliably captures - company size and a stated budget range, for example. Send qualifying leads to your CRM and create a Slack notification using the details sales actually needs to act.
Add a second route for other valid enquiries, like sending them into an appropriate nurture flow. Then add a fallback route (or logging step) for submissions that are missing qualification data. This keeps "unknown" from being treated as "not qualified" without anyone realizing it.
4. Test outcomes, duplicates, and failures
Test at least four cases: a qualified lead, a standard enquiry, a record with missing fields, and a malformed submission. Confirm each one follows the intended route and that the CRM receives the correct field values. Then test the failure path - for example, what happens if the CRM is temporarily unavailable.
Before you enable the scenario for live traffic, decide how you'll handle duplicates. Looking up by email can work for small setups, but it's unreliable when multiple people share an address or when records use different email aliases. Use the identifiers that actually make sense for your business, and document how a human should review failed or ambiguous records.
A compact workflow is easier to maintain than a sprawling one. Start with the smallest useful set of steps, then add enrichment or extra routes only when you can explain the business value. If you want to compare approaches, see our workflow automation overview and guide to API integrations.
Trade-Offs and When to Choose Another Approach
Make is a strong fit when you need visible branching, data transformation, and integrations across common business applications. Its canvas and execution history can also help operators understand what happened in a specific run. And for small teams, it can deliver an integration without requiring an engineer to build every routine handoff from scratch.
But that flexibility has trade-offs. Beginners may need time to learn how bundles, arrays, filters, and mappings work. Advanced scenarios can become hard to maintain if the original builder is the only person who understands the logic. Large payloads and high-volume workflows also require you to review platform limits and service quotas rather than assuming every transfer or execution fits your plan.
| Make may be a good fit when... | Consider another approach when... |
|---|---|
| A business process has several clear branches and uses supported applications. | The workflow is simple enough that a native integration is easier to own. |
| Ops staff need to inspect runs and adjust routine logic. | The integration needs complex business logic, strict testing, or extensive version control. |
| You can tolerate occasional delays and have a clear recovery process. | The process is safety-critical, latency-sensitive, or must meet strict uptime guarantees. |
| The workflow can be monitored and exceptions assigned to a person. | Errors could cause financial, legal, or customer harm without reliable controls. |
For high-stakes integrations, custom code is often the safer engineering choice. It can give tighter control over testing, versioning, observability, and security - but that comes with development and maintenance costs. A native app integration can be simpler too, if it covers what you need. Make sits in the middle: more flexible than a basic connector, usually less demanding than a fully custom service.
Before migrating from Zapier (or any other platform), rebuild one representative workflow and compare the full operating cost. Include setup time, execution volume, error recovery, team familiarity, and any plan limits. Claims about fixed percentage savings don't carry across organizations - your result depends on your workload and current pricing. Also review permissions, webhook exposure, data retention, and any GDPR (or other privacy) obligations that apply to your business.
A practical selection rule is simple: automate a process when it's frequent, stable, and well understood. Keep exceptions visible. Don't encode an unclear process into a scenario and expect the tool to make it reliable. Get the rules and ownership straight first - then automate the repeatable parts.