Make Scenarios and Modules

Why it matters: Make's visual builder lets non-developers build real integrations, and also lets them ship bad ones quickly. Testing with run data before scheduling is what separates a tool from a liability.

By the end you can:

• Explain scenarios, modules, and bundles
• Map fields and check types
• Use routers and filters
• Test before scheduling

Learn (15 min)

1. Scenario and module structure (5 min)

A scenario is a workflow made of modules. The first module is usually a trigger (watch for new rows, emails, or form entries); later modules search, create, update, or transform. Each module receives data from earlier ones and outputs bundles (items) that flow onward.

2. Mapping and branching (5 min)

You map earlier outputs into later inputs. Check types: a date should be a date, not free text; validate emails before writing them. A router splits flow into routes; filters let only matching bundles continue. Write conditions in plain words first:

Continue only if consent = true AND service_type is not empty.

Add a fallback route for anything that matches no filter so records never disappear.

3. Test and operate (5 min)

Run once with a safe test record. Inspect each module's input and output bubbles, not just the final status. Test a good case and a rejected case. Turn on scheduling only after you've confirmed the destination result and error behavior. Keep test data separate from production data.

Apply (15 min)

Worked example (3 min).

[Watch rows: Inquiries sheet]
   → [Filter: email not empty AND consent = TRUE]
   → [Router]
        Route A: service = "Business"  → [HubSpot: create/update contact]
        Route B: service = "General"   → [Gmail: send to info@ inbox]
        Fallback: anything else        → [Sheet: Needs Review]

Mappings: Sheet "Email" → CRM "Email"; Sheet "Name" split into first/last; "Submitted" parsed as a date.

Lab (7 min): Paper-build a scenario.

1. Sketch your own flow with a watch module, one filter, a router with two routes, and a fallback.
2. Write the filter condition for each route in plain language.
3. List five test records: two valid for each route, one invalid.
4. Predict the result for each test before running anything.

Deliverable: A diagram (text is fine) and a prediction table. You're done when: Each test record has a predicted route and a reason.

Check yourself (5 min)

1. What is a module? A bundle?
2. Router vs. filter?
3. Scenario: Records with a blank service type vanish. What did you forget?
4. Why inspect each module's output?
5. When should you turn on the schedule?

Reference

Common mistakes

Cheat sheet: Trigger module → map → filter/router → destination → inspect run details → schedule.

Key terms: scenario, module, bundle, mapping, router, filter.

Interview prompts: How do you debug a scenario that produced bad data? How do you avoid duplicates?

Go deeper: Make module types · Routers · Filtering · Scenarios

Next: Lesson 13 — the same ideas in n8n.