Make.com tutorial: build powerful automations without code in 2026

What Is Make.com and Why It Matters in 2026

Make (formerly Integromat) is a visual automation platform that lets you connect apps, APIs, and services through a drag-and-drop scenario editor. Unlike Zapier's strictly linear Zap format, Make supports complex visual flow control: branching routers, iterators that loop over arrays, aggregators that collect data from multiple iterations, and error handlers that catch and redirect failures. Unlike n8n, Make requires no server infrastructure it runs entirely in the cloud, with no DevOps overhead.

This combination of visual power without infrastructure complexity puts Make in a distinctive position. It is the platform we recommend most often for non-technical teams that have outgrown Zapier's linear model but are not ready to manage a self-hosted n8n instance. After 500+ production deployments across all three platforms, we can say with confidence that Make's scenario editor is genuinely capable for 85% of business automation use cases.

In 2026, Make has continued to expand its native integration library (now 1,500+ apps), added native AI integration for LLM calls within scenarios, and improved its error handling with more granular retry configuration. The platform has matured significantly since its rebranding from Integromat in 2022, and it deserves consideration by any business serious about automation.

Make vs Zapier: The Honest Comparison

Before going deeper into Make itself, let's address the comparison that drives most searches to this tutorial.

Zapier is easier to start with. Its editor is more polished, its 6,000+ native connectors are unmatched, and a basic two-step Zap can be running in ten minutes with zero learning curve. For simple, high-value integrations between mainstream SaaS tools HubSpot to Slack, Typeform to Google Sheets, Calendly to CRM Zapier is often the fastest path to a working automation.

Make is more capable for complex workflows. Where Zapier forces you into a linear sequence of steps, Make's scenario editor supports genuine branching logic, loops over arrays, aggregation of results, and error handling paths all through a visual interface without code. Make also wins significantly on pricing for high-volume automations. Zapier charges per task (a task is one action step in a workflow), which means a 5-step Zap running 1,000 times per month consumes 5,000 tasks. Make charges per operation, and its operation model is generally 3-5x cheaper than Zapier for equivalent workflow complexity.

The Make-vs-n8n comparison is different. n8n is more powerful (full JavaScript code nodes, self-hosted data control, zero marginal cost at scale) but requires more technical capability to operate. Make sits between Zapier and n8n on the power-versus-accessibility spectrum. Our full comparison from 500 production deployments covers this in detail.

Make Core Concepts: What You Must Understand First

Before building your first scenario, understand the five concepts that Make's entire architecture rests on. Skipping this section is the primary reason beginners end up with scenarios that work in testing and break in production.

Scenarios

A scenario is Make's equivalent of a Zapier Zap or an n8n workflow. It is the complete automation: the trigger that starts it, the modules that execute in sequence, and the connections between them. Scenarios can be simple (two modules: trigger and action) or complex (twenty or more modules with branching routers, iterators, and aggregators). A scenario runs each time its trigger fires either on a schedule, in response to a webhook, or manually.

Modules

Every action in a Make scenario is a module. A module is a single unit of work: watch for new emails, create a HubSpot contact, send a Slack message, make an HTTP request to a custom API. Modules have inputs (fields you configure, often using data from previous modules) and outputs (data that flows to subsequent modules). Make has three types of modules: triggers (the first module in a scenario, which defines what starts it), actions (modules that do something and pass output forward), and searches (modules that look up data and pass results forward).

Bundles

Data in Make flows through scenarios as bundles. A bundle is a single record of data one form submission, one email, one CRM contact. When a trigger module finds multiple records (five new form submissions since the last run, or three new CRM contacts), it produces one bundle per record. Every subsequent module in the scenario processes each bundle independently, in sequence. Understanding bundles is critical because it explains behaviour that confuses beginners: if your trigger produces 5 bundles, a Slack notification module after it will send 5 Slack messages, one per bundle.

Routes and Routers

The Router module is Make's branching mechanism. It takes one bundle as input and routes it to one of several parallel paths based on filter conditions you define. A lead routing scenario might have a router that sends high-value leads (company size above 100 employees) down one path and sends smaller companies down another. Routers can have two to many output paths, each with its own filter condition. Bundles that match no filter condition can fall through to a default path or be dropped.

Schedules and Triggers

Every Make scenario has a scheduling configuration that determines when it runs. Webhook-triggered scenarios fire immediately when the webhook URL receives a request. Schedule-triggered scenarios run at your defined interval (every 15 minutes, hourly, daily). The scheduling granularity depends on your plan: the free plan allows 15-minute minimum intervals, paid plans can schedule to every 1 minute.

For any scenario handling time-sensitive events lead notifications, payment confirmations, appointment bookings use a webhook trigger. Polling on a schedule adds unnecessary latency. Our guide on webhook vs polling architecture explains why this matters in production.

Setting Up Your Make Account

Navigate to make.com and sign up for a free account. The free plan includes 1,000 operations per month and is sufficient for building and testing the scenarios in this tutorial.

Once inside, the Make interface has three primary areas: the Scenarios list (all your automations), the Templates library (pre-built scenario starting points), and the Data Stores section (Make's built-in database for storing persistent data between scenario runs). Spend five minutes clicking through each area before building anything.

The Scenario Editor opens when you create or edit a scenario. It is a canvas where you add and connect modules by clicking the + button between existing modules. The scenario runs from left to right, though you can use routers to create parallel paths.

Building Your First Make Scenario: Form to CRM to Email

The best first scenario to build is one you will actually use: a workflow that captures a form submission, creates a CRM contact, and sends a confirmation email. This covers the core Make concepts and produces genuine business value.

Step 1 Create a New Scenario

In your Make account, click Create a new scenario. The editor opens with an empty canvas. Click the large + button in the center to add your first (trigger) module.

Step 2 Add the Webhook Trigger

Search for Webhooks and select the Webhooks module. Choose Custom webhook as the trigger type. Make generates a unique webhook URL for this scenario. Copy this URL it is the address your form will send submissions to.

In your form tool (Typeform, Tally, Gravity Forms, or your website's custom form), configure the webhook or form integration to POST submissions to this Make webhook URL. Submit a test entry from your form. Make will show a bubble indicating it received data. Click OK to save the bundle structure.

This step is critical: Make uses the first received bundle to map the data structure, showing you which fields are available to reference in downstream modules. Always send a real test submission before building the rest of the scenario.

Step 3 Add the CRM Module

Click the + button to the right of the Webhook module. Search for your CRM (HubSpot, Pipedrive, Salesforce, or another). Select Create a Contact (or equivalent) as the operation.

Map the CRM fields to the webhook data using Make's field mapping interface. Click inside any CRM field and Make shows you a list of available data from all previous modules. Select the corresponding webhook field for each CRM property: first name, last name, email address, phone number, and any custom properties relevant to your qualification process.

For the email field, consider adding a basic validation check before the CRM module. Add a Filter between the Webhook and CRM modules. A filter is a condition that must be true for the bundle to continue through the scenario. Set the filter condition to: Email address is valid. Make has a built-in email validity check function. Bundles with invalid email addresses will stop at the filter and not create garbage CRM records.

Step 4 Add the Email Confirmation Module

Click + after the CRM module. Search for your email tool (Gmail, Outlook, SendGrid, Mailchimp, or another). Select Send an Email.

Construct the confirmation email using Make's text editor, which supports variable insertion. Click any field in the email body and insert variables from previous modules: the contact's first name from the webhook, the company name from the CRM response if your CRM returns the created record data, any relevant service or product interest from the form.

For professional transactional emails, consider using SendGrid or Mailchimp rather than Gmail. These tools provide better deliverability, email tracking, and allow HTML templates. The Make module for SendGrid accepts HTML content and supports all transactional email parameters.

Step 5 Test the Full Scenario

Before activating, run the full scenario end-to-end with test data. Click Run once in the Make editor. Submit a test form entry. Watch each module execute in sequence and click the bubbles above each module to see the input and output data at every step.

Verify: the CRM contact was created with the correct data, the confirmation email arrived at the test address, and the email content includes the correct dynamic values from the form submission. Fix any mapping errors before going live.

Step 6 Activate the Scenario

Flip the scenario's Active toggle to On. The webhook URL is now live and your scenario will fire on every real form submission. Check the Scenario History tab after the first real submission to verify everything ran correctly in production.

Make Routers: Building Complex Conditional Logic

Routers are where Make's power becomes apparent. A router lets you send different bundles down different processing paths based on conditions, enabling workflows that would require multiple separate Zaps in Zapier to handle.

Building a Lead Routing Scenario

Extend the form-to-CRM scenario with lead routing. After the CRM module, add a Router module. A router icon appears with two output paths. You can add more paths by clicking the + button on the router.

Configure Path 1 for high-value leads: click the filter icon on Path 1 and set the condition Company size (from CRM enrichment or a form dropdown) is greater than 50 employees AND Service interest equals Enterprise Plan. Connect Path 1 to a Slack notification module that alerts your senior sales team with the full lead details.

Configure Path 2 for standard leads: set the condition Company size is less than 50 employees OR Service interest equals Standard Plan. Connect Path 2 to a different Slack channel notification and a task creation in your project management tool.

Configure Path 3 (click + on the router to add) with no filter condition, making it the fallback path for any bundle that does not match Paths 1 or 2. Connect Path 3 to a simple email notification to your general inbox.

This three-path router handles all lead sizes correctly without duplicating logic across multiple scenarios.

Make Iterators and Aggregators: Processing Lists of Data

Iterators and aggregators are the most powerful and least understood features in Make. They enable workflows that process arrays of data, something Zapier handles awkwardly and beginners typically avoid.

Iterators: Processing Array Items One at a Time

An Iterator module takes an array (a list of items) from a previous module and outputs one bundle per item. If your Google Sheets module returns 50 rows, adding an Iterator module after it produces 50 separate bundles, each containing one row's data. Every module after the iterator processes each bundle independently.

Practical use case: a weekly report scenario that reads all appointments from the past week from a Google Sheet (one module returning all rows as an array), iterates over them to process each appointment individually (sending a personalised follow-up email or SMS), then aggregates the results into a single summary.

Aggregators: Combining Multiple Bundles Into One

An Aggregator module does the reverse of an iterator: it collects multiple bundles and combines them into a single bundle with an array. This is useful for scenarios where you process individual records separately but need to take a single action based on all the results.

Practical use case: an e-commerce daily summary scenario that fetches individual orders (producing one bundle per order), processes each order for metrics (revenue, items, customer tier), then aggregates all processed order bundles into a single summary bundle used to populate a daily report email.

The iterator-aggregator pair is the pattern behind most batch-processing automation: fetch a list, process each item individually, combine the results for a single output action.

Error Handling in Make: Building Production-Grade Scenarios

This is the step that separates professional Make scenarios from amateur ones. Every production scenario needs error handling. Without it, a single API timeout or missing field causes the entire scenario run to fail silently.

Directive Error Handlers

Make's error handling uses directive modules that you attach to any module by right-clicking and selecting Add error handler. The error handler fires when that specific module fails. There are four directive options:

Resume: tells Make to continue the scenario despite the error, using the error output instead of normal output for downstream modules. Use this when you want the scenario to continue even if one step fails.

Ignore: suppresses the error and stops processing the current bundle, moving to the next bundle if there is one. Use this when an individual record failure should not stop the entire scenario run.

Break: stops the current scenario run and logs the error for inspection. The scenario can be configured to retry the failed bundle automatically.

Rollback: only available on plans that include transactions. Rolls back all changes made in the current scenario run if any module fails. Use this for financial or data-integrity-critical scenarios where partial completion is worse than no completion.

For most business automation scenarios, the correct combination is: Ignore on enrichment modules (continue if enrichment fails, with fallback data), Break with retry on CRM and email modules (retry up to three times before failing), and a dedicated error notification that fires whenever the scenario encounters an unrecoverable failure.

Setting Up Error Notifications

Create a separate Make scenario specifically for error notifications. This scenario has a webhook trigger. In every production scenario, add an error handler that sends a webhook to this notification scenario with the error details. The notification scenario receives the error data and sends a structured Slack alert with: scenario name, module that failed, error message, timestamp, and a link to the Make scenario for inspection.

This mirrors the error handling architecture we describe in our guide to building a 24/7 error handling system, adapted for Make's architecture rather than n8n's.

Make Data Stores: Persistent Memory Between Scenario Runs

Make Data Stores are a built-in key-value database accessible to all your scenarios. They solve the problem of scenarios that need to remember state between runs: which records have already been processed, what the current count of something is, or what the last successful run's timestamp was.

Common Data Store Use Cases

Deduplication: before creating a CRM contact, check the Data Store for a record of the contact's email. If a record exists, the contact was already processed in a previous run skip creation. If no record exists, create the contact and write the email to the Data Store for future deduplication.

Rate limiting: track how many API calls have been made in the current hour in a Data Store counter. Before each API call, check the counter. If the counter has reached the API rate limit, use a Make sleep function to pause before continuing.

Cross-scenario communication: write data from one scenario to a Data Store, and read it from a different scenario. This is how you build multi-scenario systems where the output of one automation becomes the input of another.

Make Advanced Features: Webhooks, Custom Apps, and Scheduling

Instant Webhooks vs Scheduled Polling

Make supports two classes of triggers: instant (webhook-based, fires immediately when the external event occurs) and scheduled (polling-based, checks for new data on your defined interval). Whenever the source application supports webhooks, always use the instant trigger. It is faster (milliseconds vs up to 15 minutes latency), more efficient (no wasted API calls during idle periods), and more reliable (no polling gaps during high-volume periods).

For apps that only support polling, set your interval to the minimum your plan allows and accept the latency trade-off. The webhook vs polling architecture decision is the same in Make as in any other automation platform.

Make's HTTP Module: Connecting to Any API

For services without a native Make module, the HTTP Make a request module connects to any REST API. Configure the method (GET, POST, PATCH, DELETE), URL, headers (including API key authentication), and request body. The response is available as bundle data for downstream modules.

This is how PURIST connects Make to niche or industry-specific applications that do not have Make connectors: dental practice management systems, real estate MLS APIs, custom internal databases. If an application has a REST API and documentation, Make can connect to it via the HTTP module.

Webhooks for Outbound Events

Make can also send webhooks to external systems using the Webhooks > Send a webhook module. This is how you trigger external systems including n8n workflows from Make scenarios. A common hybrid architecture uses Make as the visual front-end for business users who configure simpler scenarios, with complex processing handled by n8n workflows that Make triggers via webhook.

Make Pricing Breakdown: What You Actually Pay

Make pricing is based on operations. An operation is one module execution: one API call, one data transformation, one email send. A scenario with five modules that runs 1,000 times per month consumes 5,000 operations.

Make Free: 1,000 operations per month, 2 active scenarios, 15-minute minimum scheduling interval. Sufficient for testing and very light use.

Make Core: $9/month (annual billing), 10,000 operations per month, unlimited active scenarios, 1-minute minimum scheduling interval, access to premium apps.

Make Pro: $16/month (annual), 10,000 operations with higher team features, full operations history, priority support.

Make Teams: $29/month (annual), 10,000 operations, team collaboration features, shared scenario management.

Additional operations can be purchased in packs at approximately $9 per 10,000 additional operations. For businesses running 100,000+ operations per month, Make Pro or Teams plus operations packs remains significantly cheaper than Zapier's equivalent tier.

Make vs Zapier Cost Comparison at Scale

At 50,000 operations/tasks per month: Make Core plus operations pack costs approximately $54/month. Zapier Business plan costs $69/month for 75,000 tasks nominally cheaper per task, but Zapier's task counting (one task per step) versus Make's operation counting (also one operation per module execution) makes direct comparison nuanced. In our deployments, equivalent workflows typically cost 30-50% less on Make than on Zapier at moderate volume.

At 500,000 operations per month: Make becomes expensive. This is the volume threshold where self-hosted n8n's zero marginal cost becomes the economically compelling choice. Our Zapier alternatives guide covers the full cost comparison.

When to Choose Make Over n8n or Zapier

Choose Make when you need complex visual workflow logic (routers, iterators, aggregators) but do not have the technical resources to manage a self-hosted n8n instance. Make is the right platform for marketing teams, operations managers, and business analysts who need more automation power than Zapier provides without needing to involve a developer.

Choose Make over Zapier specifically when: your workflow requires branching logic or loops, you process arrays of data (lists of records, rows from a spreadsheet), your operation volume makes Zapier's pricing punishing, or you need fine-grained error handling at the module level.

Choose n8n over Make when: you need self-hosted data control (GDPR, healthcare, financial services), you are processing very high volumes where Make's per-operation cost becomes significant, you need custom JavaScript logic that visual modules cannot express, or you want to integrate AI agents via the native Claude node with full control over prompt construction. Our how to automate your business playbook includes a full tool selection framework.

Make's visual router-iterator-aggregator system is the most powerful no-code flow control available in any automation platform. If you think you need code to build complex automation logic, try Make's visual tools first. You may be surprised how far they take you without a single line of JavaScript.

Make Tutorial FAQ

Is Make.com free to use?

Make has a free plan with 1,000 operations per month and 2 active scenarios. This is sufficient for testing and very light personal use. For business automation with multiple scenarios and meaningful operation volumes, paid plans start at $9/month.

What is the difference between a Make scenario and a Zapier Zap?

Both are visual automation workflows with a trigger and action sequence. The key differences: Make supports branching (routers), loops (iterators), and data aggregation that Zapier's Zap format does not support natively. Make's operation pricing is generally cheaper than Zapier's task pricing at moderate to high volumes. Zapier has a larger native connector library (6,000+ vs Make's 1,500+).

Can Make.com connect to custom APIs?

Yes. The HTTP Make a request module connects to any REST API without requiring a native Make connector. If the API has documentation and standard HTTP authentication (API key, OAuth, basic auth), Make can connect to it.

How does Make handle errors?

Make has directive error handlers that attach to individual modules. When a module fails, the error handler fires and executes a configured directive (Resume, Ignore, Break, or Rollback). For production scenarios, configure error handlers on every critical module and set up a dedicated error notification scenario that alerts your team when scenarios encounter unrecoverable failures.

Is Make suitable for healthcare or financial services data?

Make is a cloud-only platform your data is processed on Make's infrastructure in their European or US data centres. Make is GDPR compliant and SOC 2 Type II certified. For workflows handling particularly sensitive healthcare or financial data where you need complete data sovereignty (data never leaves your own infrastructure), self-hosted n8n is the correct platform choice. For most European SMB GDPR compliance requirements, Make's certifications are sufficient.