TL;DR — You can build your first working Make automation in about ten minutes — the trick is doing three small things first so you don't get stuck. This Make tutorial walks you through the setup, a real first scenario (email attachments → Google Drive), a more useful second one, and the beginner mistakes that quietly waste time and credits.
Before you build: three minutes that save an hour
Make's learning curve is real, but most early frustration comes from skipping setup, not from the platform itself. Do these first. Connect your apps up front: go to Connections in the left sidebar and authenticate the tools you'll use (say Google and Slack) before you start building, so you're never interrupted mid-scenario to log in.[1] Turn on limit warnings: in your account settings, enable email notifications for when you approach your operation/credit limit — far better than discovering automations stopped after the fact.[1] And decide the process before the tool: write your automation as a plain sentence ("when an email with an attachment arrives, save the file to Drive") — trying to learn Make before you know the process you want is the single biggest source of beginner confusion.[1]
Give modules and scenarios clear, descriptive names from the start — future-you debugging a 12-module scenario will be grateful.
Your first scenario, step by step
Let's build the classic starter: save Gmail attachments to Google Drive automatically.
- From the dashboard, click Create a new scenario.
- On the empty canvas, click the + and search Gmail; choose Watch Emails as the trigger. This is what starts the automation.[1]
- Add a second module: click +, search Google Drive, choose Upload a File.
- Map the data — in the Drive module, set the file input to the attachment coming from the Gmail module (Make shows the previous module's output as clickable fields). Pick the destination folder.
- Click Run once to test on a real email before you schedule anything (more on this below), then toggle the scenario on.
That's a complete, useful automation with two modules. The pattern you just learned — trigger, then one or more actions with data mapped between them — is the whole of Make; everything else is just more modules and smarter logic.
Understanding what you just built
Two concepts trip up more beginners than anything else, and five minutes here saves a lot of confusion later.
Mapping is the whole game. Each module produces output — the Gmail trigger, for instance, outputs the sender, subject, body and any attachments. When you click into a field on a later module, Make shows those outputs as clickable, color-coded tags. "Mapping" is simply clicking the tag you want (the attachment, the sender's email) so the later module uses live data from the earlier one, not a value you typed in. If a field later shows up empty or errors, mapping is the first place to look — nine times out of ten the tag you expected wasn't actually mapped, or the trigger didn't produce it on that run. (A common early scare: the tag list looks empty before you've ever run the module — run the trigger once and the real fields appear.)
The operations counter tells you what it costs. After a Run once, each module shows a small number — the operations it consumed. That's your live cost meter: a trigger plus one action that ran once is ~2 operations. Watch it as you build and you'll develop an instinct for which scenarios are cheap and which will burn credits at volume — long before a bill ever surprises you. It's also the fastest way to spot an accidental loop running far more operations than you intended.
A more useful second scenario
Once the pattern clicks, build one with a branch of real value: every Google Form submission → a new row in Google Sheets → a Slack notification.[1] Trigger on the form, add a Sheets "Add a Row" module mapping the form fields, then add a Slack "Create a Message" module. Want it to only alert on certain answers? Add a filter between modules so it fires only when, say, the enquiry is marked urgent. That single filter is also a credit-saver — which brings us to the mistakes worth skipping.
The beginner mistakes to skip
Four missteps trip up almost everyone, and all are easy to avoid:
- Not testing before going live. Always use Run once on real data first; it's the cheapest bug insurance Make gives you.[1]
- No filters. Without a filter right after the trigger, a scenario runs on everything — including test records and empty checks — wasting operations and sometimes doing the wrong thing.[1]
- Ignoring the logs. Check the execution history when something misfires; Make shows you exactly which module failed and why.[1]
- Building big too soon. Start simple and add complexity once the basics run; the depth is there when you need it, but reaching for it on day one is how people overwhelm themselves.[1]
Every 'Run once' consumes operations. Test deliberately rather than spamming runs while you learn — and add a filter so live runs don't fire on empty checks.
When things break: debugging basics
Automations fail — APIs go down, data formats change, rate limits get hit — so knowing where to look saves hours. Make keeps an execution history for every scenario: open it, find the run that failed, and it shows you the exact module that errored and the data it choked on.[2] Most beginner failures trace to a handful of causes: a missing or renamed field the mapping expected, an unmapped required field, or rate limits on busy HTTP calls, iterators or webhooks.[2]
The upgrade that separates hobby scenarios from production ones is error handling. By default, if a module fails, everything downstream stops — and it can fail silently for days if you're not watching.[2] The fix: attach an error handler route (the red route) from any critical module to a fallback — a Slack notification so you hear about it, a Data Store write to log it, or a retry directive so a transient blip doesn't kill the run.[2] It's ten minutes of setup that turns "why did this quietly stop last Tuesday?" into an alert you actually get.
Right-click a critical module → add an error handler route to a Slack alert or Data Store log. Ten minutes now turns a silent multi-day failure into an alert you actually get.
Tips & tricks that save real money
Once your automations run often, a few power-user habits separate a $9 month from a surprise bill — these are the ones worth internalising early:
- Webhooks beat polling, every time. A scheduled (polling) scenario wakes up every interval to check for data and spends credits even when there's nothing new; a webhook only fires when an event actually happens. Switching a busy trigger from polling to a webhook can slash its credit use dramatically.[3]
- Bring your own AI key for high volume. Make's built-in AI modules are convenient but cost more operations than calling the model yourself. For heavy AI workflows, use the HTTP module with your own OpenAI/Anthropic key to cut credit consumption.[3]
- Unused operations roll over one month on paid plans — a genuinely useful quirk that can save $50–100/mo on seasonal or bursty workflows, so don't over-buy for a spike you can smooth out.[3]
- Filter at the trigger so you never process (and pay for) test records, duplicates or empty checks.
- Build reusable sub-scenarios — a "clean this data" or "notify the owner" scenario you call from bigger ones — so your tenth automation takes an afternoon, not a week.
- Annual billing trims ~15% once a workflow has proven itself worth keeping.[3]
Automations worth copying
The fastest way to learn Make is to rebuild a proven pattern rather than invent one. A few real-world scenarios, with the kind of results teams actually report:
- Order processing (e-commerce): a Spanish building-materials retailer, Habitium, automated its order flow with Make and cut average processing from 15 minutes to 1 minute per order.[4]
- Lead response (real estate): capturing Facebook/Meta ad leads straight into a CRM with instant routing took one firm's lead-response time from 5 hours to 10 minutes, lifting conversions ~23%.[4]
- Content repurposing: watch a WordPress RSS feed for new posts, have an AI step format platform-specific copy, and push it to Buffer to schedule across X/LinkedIn — one input, a week of distribution.[4]
- Lead capture: a form submission → dedupe in a Data Store → enrich → write to your CRM → routed Slack alert, so no lead sits unseen.
Start by cloning the one closest to your own job, wire in your apps, and test it with Run once before scheduling. That's how a beginner becomes a power user — not by studying every module, but by shipping one real automation and extending it.
Leveling up: the three features that do the real work
Once the trigger-then-actions pattern is second nature, three features take you from simple pipes to real workflows — and they're where Make's power actually lives.
Routers — branch down multiple paths. A router splits a scenario based on conditions, so one trigger can do different things depending on the data. Example: a new deal comes in; if its value is over $10k, route it to a Slack channel for senior sales and create a task; otherwise, drop it into a nurture sequence. One scenario, two outcomes, no duplication.
Iterators (and aggregators) — handle lists. An iterator loops over an array so each item runs through the following modules, and an aggregator collapses the results back into one bundle. Example: an order arrives with twelve line items; the iterator processes each one, then an aggregator rebuilds a single summary to write back or email. This is also the pattern to watch for cost — each item runs every downstream module — so it's where filters earn their keep.
Data stores — give your scenarios memory. A data store is a lightweight built-in database. Its two killer uses are deduplication (record what you've already processed so you never handle the same item twice) and state (remember a value between runs). Example: a content queue that checks the data store before drafting, so a re-published RSS item never gets posted twice.
Learn these three and you can build most of what businesses actually run on Make. Everything past them — webhooks, custom functions, the HTTP module, AI agents — is an extension of the same mental model.
When you catch yourself building near-duplicate scenarios that differ by one condition, collapse them into a single scenario with a router — easier to maintain and cheaper to run.
Where to go next
You now have the core loop — trigger, actions, mapping, filter, test. From here, three directions pay off: learn routers to branch a scenario down multiple paths, iterators to loop over lists, and data stores to remember state between runs. If AI is on your roadmap, our Make AI Playbook shows how to add agents and LLM steps the right way. And before you scale up, skim our pricing guide so you understand how credits are consumed — the difference between a $9 month and a surprise is mostly scenario design. For the full picture on whether Make is your long-term home, see the complete Make review.
Frequently asked questions
How do I build my first scenario in Make?+
Create a scenario, add a trigger module (the app and event that starts it — say, a new form submission), then add action modules that do something with that data (create a row, send a message). Connect them on the canvas, map the trigger's data into each action's fields, then run once to test before turning it on. Your first working scenario takes minutes.
What's the difference between a module and a scenario in Make?+
A scenario is the whole automation — the connected workflow on the canvas. A module is a single step within it (one app action or a piece of logic like a filter or router). Scenarios are built by chaining modules, and since each module run is one operation, understanding modules is also how you understand your cost.
How do I connect an app Make doesn't natively support?+
Use the HTTP module. If a service has an API but no dedicated Make app, the HTTP module lets you call that API directly — sending requests and parsing responses — so you're rarely blocked by a missing integration. It takes a little more setup than a native module but requires no separate coding environment.
What are the most common beginner mistakes in Make?+
The big ones: not filtering early (so modules run — and cost operations — on data you don't need), forgetting error handling so a single failure stops the scenario, and over-polling triggers that quietly drain your operations. Building with filters up front and adding error routes to important scenarios avoids most early pain.
How do I debug a scenario that isn't working?+
Use Make's execution history — every run is logged with the exact input and output of each module, so you can open a failed run and see precisely which module broke and why. Run once manually to reproduce the issue, inspect the data bundle passing between modules, and check field mapping, which is the most common culprit.