# Make.com Tutorial: Automate Your First Workflow in 20 Minutes

**By StackTrekker Editorial** · Published September 11, 2026 · Updated September 29, 2026
If a tool promises to save you an hour a day and then greets you with a blank canvas, the promise dies on the first screen. Make.com is worth pushing past that, because what waits on the other side is a visual automation builder: you drag modules, connect them, and watch data move between the apps you already use.

This tutorial takes you from an empty scenario to a working automation in about twenty minutes. Every new Google Form response lands in a Notion database, with no manual copying. No code, no API keys, and no prior automation experience. Each step maps to the current Make builder, and the same building blocks apply to every scenario you build afterward.

## What Make.com actually is

Make is a visual automation platform. You build a **scenario**: one trigger (the event that starts things) followed by modules (the steps that run in response). Each module talks to a specific app, so a scenario is really a short assembly line for your data.

Two things set it apart from simpler tools:

- **The canvas is visual.** You see the whole flow, including branches and loops, instead of a numbered list of tasks.
- **Logic comes built in.** Filters, routers, iterators, and error handlers let one scenario handle messy real-world cases that would otherwise need a second, third, and fourth automation.

If your automations are always "one thing happens, one thing follows," Zapier is the easier starting point, and our [Zapier + Notion workflow guide](/zapier-notion-workflows/) covers that style. Come back to Make when your logic starts branching.

## The five words you need before you start

Vocabulary is the real barrier with Make. Five terms cover most of what you will ever do:

| Term | What it means |
|---|---|
| Scenario | The whole automation, start to finish |
| Trigger | The first module: the event that starts the scenario |
| Module | One step in the flow, an app action or a tool |
| Connection | Saved login for an app, authorized once and reused |
| Operation | One module run; this is the unit Make counts usage by |

Operations matter because they decide your cost. A polling trigger that checks every fifteen minutes spends operations even when nothing changed, while a webhook fires only when an event actually occurs. The [Make Help Center](https://help.make.com/) documents how each module type is billed before you commit to it. If your allowance is already draining faster than the work justifies, our [Make.com operations limit fix](/make-com-operations-limit-exceeded/) covers the settings that cause it and how to cap each one.

## Step 1: Create the account and open the builder

Sign up at Make with an email address or a Google account. The free plan is enough for this tutorial: it gives you a real scenario builder and a monthly operations allowance, so nothing below sits behind a paywall.

On the dashboard, click **Create a new scenario**. You land on an empty canvas with a large plus button in the middle. That button is where every automation starts.

## Step 2: Choose your trigger

Click the plus, then search for the app that starts your automation. For this walkthrough, choose **Google Forms** and pick a **Watch Responses** module. The word "Watch" is Make's naming for a trigger.

Make then asks two things:

1. A connection. Click **Add**, sign in to the app in the popup window, and approve access. The connection is saved, so you authorize once and reuse it everywhere.
2. A setup detail. For Google Forms, choose the specific form Make should watch.

You now have a trigger bubble on the canvas with a small circle on its right edge. That circle is the output, and everything you add next hangs off it.

## Step 3: Add the action module

Click the plus to the right of the trigger and search for **Notion**. From the list, choose **Create a Database Item**.

Fill the module in this order:

1. **Connection:** add and authorize your Notion account. Grant access to the specific page or database you need, not your whole workspace, unless you have a reason.
2. **Database:** pick the target database from the dropdown. If it is missing, the connection does not have permission yet, so reopen the authorization and select that database.
3. **Fields:** this is where the mapping happens.

If the destination does not exist yet, build it first. Our [Notion database beginner guide](/notion-database-beginner-guide/) walks through properties and views in ten minutes. A database with a Name property, a Status select, and a Date property is plenty for this scenario.

## Step 4: Map the data (check these fields)

Mapping means telling Make which incoming value fills which field. Do not type values by hand into the module. A hard-coded value is the same on every run, which defeats the whole point of the automation.

Click into the **Name** field. A panel opens showing the trigger's output. Pick the form question that represents the title, and Make inserts a purple tag such as `1. Name`. That tag is a live reference that updates on every run.

For the date field, use a built-in function instead of raw text. In the mapping panel, open the **Date and time** functions and apply `formatDate(now; "YYYY-MM-DD")`. The semicolon separates arguments in Make's function editor, and the wrong separator is one of the most common silent failures.

Map at least these three:

- Title (a form answer, mapped)
- Date (the function above)
- Source (plain text such as "Google Form")

Leave anything you cannot map confidently set to empty rather than guessing. An empty field is easy to spot; a wrong mapping quietly corrupts every record.

## Step 5: Test the scenario

Click **Run once** at the bottom of the builder. Make goes into listening mode on the trigger. Now submit a real test response on your form.

The bubbles light up as the scenario runs. A green check on a module means it succeeded. Click any bubble and you can inspect its input and output data, which is exactly how you find out why a field came through empty or in the wrong format.

If the run fails, the error message names the module and the reason. The two you will meet first are an expired connection and a mapping that points at a field you renamed after editing the form.

## Step 6: Schedule it and switch it on

Click the clock icon on the trigger to open **Scheduling**. This is where you choose how often Make checks for new data.

- **Immediately:** runs as soon as new data appears, available on some triggers and paid plans.
- **Every 15 minutes**, or a longer interval: Make polls the source on a timer. This is the normal free-plan setup for form and spreadsheet triggers.

Pick the longest interval your work actually needs. A support inbox might need fifteen minutes; a weekly report generator does not, and a shorter interval only spends operations faster.

Finally, toggle the scenario **On**. The switch sits at the bottom left of the builder. Until you flip it, a scenario run by hand works while the scheduled version stays off, which trips up plenty of first-time users.

## Step 7: Read the history when it breaks

No automation runs perfectly forever. When yours goes quiet, open the **History** tab for the scenario. You get a list of every run with a status, and clicking a run shows each module's input and output exactly as it happened.

Four failures cover most beginner incidents:

1. **Authorization expired.** The connection shows an error and every run stops. Reconnect the account and the scenario resumes.
2. **A field was renamed.** You edited the form or the Notion property name, and the mapping now points at nothing. Update the mapping in the module.
3. **A filter blocks everything.** If you added a filter, check it against a real bundle rather than an imagined one.
4. **A bundle validation error on one run.** The next module rejected the data it received. Our [Make.com bundle validation error fix](/make-com-bundle-validation-error/) walks through the field checks that clear it.

When a webhook-based scenario stops firing entirely and the history shows nothing at all, the cause usually sits outside Make. Our [Zapier webhook troubleshooting guide](/zapier-webhook-error-fix/) covers that class of problem, and the debugging order is the same regardless of tool.

## Mistakes to skip on your first build

- **Building big first.** Get a three-module scenario running end to end before you add branching. A working simple scenario teaches more than a broken clever one.
- **Skipping filters.** A trigger that fires on every event will flood your database. Add the filter early.
- **Ignoring error handlers.** Right-click a module and add an error handler so one failed run does not silently stop the chain.
- **Typing values instead of mapping them.** Any value that should change between runs belongs in the mapping panel, not the text box.
- **Forgetting the timestamp.** Add a created-date field now. Six months from now you will want to sort by it, and it cannot be backfilled.

## Where to go next

You now have the pattern every Make scenario follows: trigger, action, mapping, test, schedule, monitor. The next step is to build a second scenario with a filter and an error handler, because that is where Make pulls ahead of simpler tools.

Pair it with the rest of your stack. The [Notion task system](/notion-task-system/) gives the database you just filled a job to do, and this [free Notion task template](/free-notion-task-template/) gives you a structure to copy instead of building properties from scratch. One good automation feeding one good system beats ten half-built ones every time.

## Sources

- [Make Help Center](https://help.make.com/)
- [Make documentation: scenarios](https://help.make.com/scenarios)
- [Make documentation: connections](https://help.make.com/connections)
- [Notion Help Center](https://www.notion.com/help)

---

Source: https://stacktrekker.com/make-com-tutorial/