Loading tutorials…
Loading tutorials…
You signed up for Make and the scenario builder is staring at you. This walks through one real, working scenario end-to-end — without the marketing fluff.
Who this is forOwners and operators with a configured Make organization who need their first scenario actually running today. If you have a clear "when X happens, do Y" already in your head, this gets you live in 45-60 minutes.
What you'll need
Step 1
Before opening Make, write the automation as a single sentence: "When [trigger event] happens in [App A], create/update [object] in [App B]."
The fastest way to build a broken scenario is to start building before you know what you want.
Open a notes file. Write: "When [specific event] happens in [specific app], I want [specific outcome] in [specific app]."
Example: "When a new row is added to the Leads Google Sheet, create a contact in HubSpot with the email, first name, and company columns mapped."
If the sentence has more than one verb or two apps, it is more than one scenario. Pick the first one and ship it. You can chain later.
If you cannot write the sentence, you are not ready to build. Most automation debt starts here.
Step 2
Scenarios → + Create a new scenario. Skip templates for your first build — you want to learn the canvas.
Log in to make.com. Click "Scenarios" in the left nav.
Click "+ Create a new scenario." You land on the blank canvas with a single starter module (the big + circle).
Skip templates for your first build. Templates are useful once you understand the canvas, but they hide the build steps you need to learn.
In the top-left, rename the scenario from "Untitled Scenario" to something descriptive: "[Trigger app] → [Action app]: [outcome]." Future-you with 30 scenarios will thank you.
Step 3
Click the starter module → search for your trigger app → choose a trigger event → connect → test.
Click the big + circle. A module search opens.
Search for your trigger app (e.g., "Google Sheets," "Typeform," "Shopify").
Choose the event. Read carefully — "Watch Rows" and "Watch Changes" sound similar but fire on completely different conditions.
Select the connection (the reusable connection you created in foundation setup). If you do not have one, you can create it here, but it is cleaner to set up connections beforehand.
Configure the specific resource: which spreadsheet, which sheet (tab), which range. Make is more granular than Zapier here — specify everything.
Set "Limit" — max records to process per run. Start with 1-2 for testing. Raise to 10-100 for production once tested.
Click "OK." Right-click the module → "Run this module only." You should see sample data appear if the source has any.
Step 4
Right-click the trigger → "Add another module" → search the action app → choose action → connect → map fields.
Hover over the trigger module. A small + appears on the right edge. Click it.
Search for the action app. Choose the action (Create Contact, Send Email, Add Row, etc.).
Select or create the connection.
Map fields: for each field in the action module, click it. A right panel opens showing available data from the trigger. Click the corresponding field.
Example: action "Create HubSpot Contact" → click the Email field → in the right panel, click "Email" from Google Sheets. Make inserts a token like {{1.Email}}.
Map only the fields you need. Skipping optional fields keeps the action faster and cleaner.
Click "OK." Right-click the module → "Run this module only" with a small test record to verify the mapping works.
Step 5
Bottom-left → "Run once." Make executes the trigger AND action together with real data. Verify both succeed.
At the bottom-left of the canvas, click "Run once."
Make polls the trigger for new data. If a record matches, it processes through every module.
Each module shows a small number — the count of executions. Green = success. Red = error.
Click any module to see the input/output bundle. Confirm the data passing through is what you expected.
If the trigger pulls 0 records (the source is empty), add a real test record and re-run.
If a module errors, click it. The error message tells you what is wrong. Usually a missing required field, an invalid format, or insufficient permissions.
Step 6
Bottom-left → Scheduling icon (clock). Set: On-Demand (manual), Immediately (real-time webhook), Every X minutes, or specific times.
Click the clock icon at the bottom-left.
Options: "On Demand" (you manually run), "Every X minutes" (polling — cheaper but delayed), "Immediately" (real-time webhook — only for webhook triggers).
For most production scenarios, "Every 15 minutes" is the right balance of speed vs operations cost.
For time-sensitive flows (cart abandonment, real-time notifications), use webhook triggers or "Immediately."
Save the schedule. The scenario is still OFF — switching to scheduled does not auto-activate.
Step 7
Bottom-left → toggle "Off" to "On." Scenario starts running on schedule. Watch History tab for first 24 hours.
Confirm one final time the test run was successful. Do NOT activate a scenario that has not been tested with a real Run Once.
Toggle the scenario switch from "Off" to "On" (bottom-left).
Make immediately starts polling on schedule.
Open History tab. Within 15 min you should see the first scheduled run.
For the first 24 hours, check History 2-3 times. Confirm runs succeed and operations consumed match expectations.
Set up notifications (Profile → Notifications) so you get alerted on failures.
Common mistakes
Activating without a successful Run Once test
What goes wrong: You toggle the scenario on, leave for the day, come back to find it errored every 15 minutes for 8 hours — 32 failed runs consuming operations and possibly half-writing data downstream.
How to avoid: ALWAYS Run Once successfully end-to-end before activating. The 90 seconds you save by skipping the test costs hours of cleanup.
Triggering every minute when you do not need to
What goes wrong: Every-minute polling on a Google Sheets trigger that gets 5 rows/day = 1,440 ops/day wasted polling empty. 43,200 ops/month gone with nothing to show.
How to avoid: Match polling frequency to data velocity. Every 15 min for typical leads/orders. Every hour for batch syncs. Webhook triggers for real-time needs (consume 1 op per event, not per poll).
Mapping every available field instead of needed fields
What goes wrong: Mapping 30 fields when the action only needs 5 doubles the bundle size and slows execution. Some APIs reject overlong payloads silently. Hidden failures.
How to avoid: Map ONLY the fields the action requires + a few you might want for downstream filters. Skip the rest. Cleaner, faster, more reliable.
Not setting the Limit on Watch triggers
What goes wrong: If 200 rows are added to a sheet between runs (unlikely but possible — bulk import), Make tries to process all 200 in one execution. Hits time/operation limits, scenario halts mid-batch, half the data is missing downstream.
How to avoid: Set Limit = 10-50 for most Watch modules. Make picks up the rest on subsequent runs without overloading any single execution.
Skipping error notifications
What goes wrong: Without scenario failure notifications, broken scenarios run unnoticed for days or weeks. You discover the issue only when a downstream system or customer complains.
How to avoid: Profile → Notifications → enable email alerts on scenario errors. For multi-person teams, also pipe to Slack via the Make → Slack notification connector.
Recap
Done — what's next
How to set up your Make.com account and workspace
Read the next tutorial
Hand it off
Make rewards careful scenario design. A specialist will build 5-10 scenarios with operations efficiency in mind — typically reducing consumption 30-50% vs DIY builds. From $14-16/hr — most first-scenario builds land at $200-500.
See specialist rates
Make uses a visual canvas (vs Zapier's linear list), bills per module execution (vs per workflow run), supports more complex logic (routers, iterators, aggregators), and is 30-60% cheaper at high volume. Steeper learning curve but more flexibility.
On Core plan: every 15 minutes minimum. Pro plan: every 5 minutes. Webhook triggers fire immediately regardless of plan (real-time).
Polling for your first build — easier to debug and works for most apps. Webhooks are more efficient but require setting up the source app to send events (Webhook URL config). Move to webhooks once you understand the basics.
Right-click any module → 'Run this module only.' Make executes just that module with whatever data is in the upstream bundle. Lets you debug one module at a time without burning operations on the whole flow.
Default behavior depends on Error Handling settings (Scenario Settings → Advanced). 'Stop' halts the scenario; 'Resume' continues with the next bundle; 'Rollback' undoes everything. For most flows, set to 'Resume' so partial failures do not block the whole batch.
Make
Make.com (formerly Integromat) is more flexible than Zapier but more punishing if you skip foundations. This walks the setup that prevents 90% of "why is this broken" questions later.
Make
Routers and filters are how scenarios stop being linear toy automations and start handling real-world conditionality. This is the structure that prevents 1,000-line debug sessions.
Make
Production scenarios will fail. APIs go down, rate limits hit, data is malformed. The question is whether your scenario recovers gracefully or silently breaks. Error handlers are the difference.
Zapier
You signed up for Zapier and the dashboard is staring at you. This walks through one real, working Zap end-to-end — trigger app, action app, sample data, test, turn on — without the marketing fluff.