How to Build Your First Scenario in Make.com

You have a repetitive job that crosses two apps. A form response should land in a spreadsheet. A new order should post to a team channel. Make is a very good tool for exactly this shape of work, and its visual canvas is one of the clearest in the category once the vocabulary clicks.

The vocabulary is the part that trips people up, not the clicking. Make calls the whole automation a scenario. Each block on the canvas is a module. The packet of data travelling between modules is a bundle. Once those three words are solid, the rest of the interface reads naturally.

What is a scenario in Make?

A scenario is one automation: a trigger module followed by the modules that act on whatever the trigger produced. It runs on a schedule you choose, or the moment data arrives if the app supports an instant trigger.

Everything downstream depends on the trigger's output, so choosing it well matters more than any later step. Pick the app that genuinely knows first that the event happened. If the form is the source of truth, watch the form, not the spreadsheet it writes to.

What do you need before you start building?

You need an account, the apps you want to link, and a decision about what a successful run looks like. Make offers a free plan, which their pricing page listed on 17 August 2026 as up to 1,000 credits per month, enough to build and test a simple scenario.

It saves time to authorize your apps before you start rather than mid-build. Each app you use needs a connection, which is the stored authorization Make uses to act on your behalf. You can create one from inside a module the first time you add it.

How do you add the trigger and the first modules?

You create a new scenario, then click the empty module placeholder on the canvas and search for your app. Make groups each app's modules by what they do: triggers watch for something new, actions create or update a record, searches look things up and can return many results at once.

Add one action to start. Resist the urge to build all six steps before testing any of them, because a broken mapping in step two is far easier to see when steps three through six do not exist yet.

Building a first scenario end to end

1. Create the scenario — From your Make dashboard, start a new scenario. You land on an empty canvas with a single module placeholder in the middle.
2. Add the trigger module — Click the placeholder, search for the app that knows about the event first, and choose one of its watch-style trigger modules. Create the connection when prompted.
3. Pull in sample data — Run the scenario once so the trigger captures a real record. Working with real sample data rather than placeholders is what makes the next step easy.
4. Add the action module — Click the plus after the trigger and pick the app that should receive the data. Choose the specific action, such as adding a row or sending a message.
5. Map the fields — Click into each field of the action and pick values from the trigger's output rather than typing them. Mapped values appear as tokens, not as free text you retyped.
6. Test with Run once — Run the whole chain and inspect each module's output bubble. Confirm the row actually appeared or the message actually sent before you trust the run history.
7. Choose a schedule and switch it on — Open the schedule settings, pick the timing that matches the work, then activate the scenario so it runs without you.

How does mapping data between modules work?

Mapping is how a later module reads a value the earlier module produced. You click into a field, and Make shows a panel of the available values from every module above it, grouped by which module they came from.

The single most common beginner mistake is typing a value that looks right instead of selecting it. Typed text is static, so it will be identical on every run. If the second run writes the first run's name, an unmapped field is almost always the cause.

If a value you expect is not in the panel, the module above probably has not produced sample data yet. Run the trigger once more so Make learns the shape of the incoming record, then reopen the field.

How do you schedule a scenario?

Make's documentation states that scenarios run every 15 minutes by default, and that you open the schedule settings from the toolbar in the scenario builder. From there you choose how often the scenario should look for new work.

Their scheduling documentation lists these schedule types: at regular intervals, once, daily, weekdays Monday to Friday, weekly, monthly, specified dates, and on demand. On demand means the scenario only runs when you trigger it yourself, including via the Run once button. Advanced settings let you give an active scenario a start and end date.

Instant triggers are different. Make's documentation describes them as running immediately as data arrives, with a rate limit setting for the maximum runs to start per minute, defaulting to 100. It also notes that when a scenario contains a webhook response module and exceeds that limit, the caller receives an HTTP 429 too many requests error and has to retry.

What does a scenario cost to run?

Make bills in credits, and their documentation states that for most features one operation equals one credit. Roughly speaking, every module that processes a bundle spends a credit, so a five-module scenario that fires 200 times a month is in the neighbourhood of 1,000 credits, not 200.

This is the arithmetic worth doing before you commit to a design, because module count multiplies by run count. We wrote a separate walkthrough of how credits are consumed and where the usage usually hides.

When is a scenario the wrong tool?

A scenario is excellent at deterministic plumbing: this field goes into that field, every time, in the same way. It is a harder fit when a step needs judgment, because judgment does not decompose neatly into filters and branches.

If your honest description of the task contains the words "it depends", you will end up encoding that dependency as an ever-growing tree of routes. That tree is buildable in Make. It is just a lot of maintenance for something you could have said in a sentence.

Set-up work like this is exactly what we removed at Sistava. Rather than wiring a trigger to an action and testing the path, you hire an AI Employee and tell it, in plain English, what you want handled. It has the tools connected already, it asks you when it is unsure, and it sets itself up. No flow to build, nothing to maintain.

Neither approach wins outright. Fixed pipelines belong on a canvas. Work that requires reading, deciding, and following up belongs with something that can read, decide, and follow up.

What goes wrong on a first build?

The three recurring problems are an unmapped field, a trigger that fires on the wrong event, and a scenario that reports success while nothing happened downstream. All three are caught the same way: after a test run, go and look at the destination app, not just the run history.

• Static text where a mapped value belongs, so every run writes the same thing.
• Watching a destination app instead of the true source, so records arrive late or twice.
• Building six modules before testing any, which hides where the failure started.
• Switching a scenario on before checking what happens on an unusual record.
• Forgetting that a search module can return many records, which multiplies everything after it.

Sources

• Make Help Center, Schedule a scenario, for default interval, schedule types, and instant trigger rate limits.
• Make Help Center, Scenarios, for scenario settings, variables, and execution concepts.
• Make Help Center, Credits, for how operations map to credits.
• Make pricing page, read on 17 August 2026.
• WorkflowPick, Make.com tutorial for beginners, an independent step-by-step first build.