Make.com Automation

This workbook turns the course into a working Make.com practice: an inventory of the manual tasks worth automating, a first two-module scenario, a mapping and filtering plan, a branching and looping design, and an error-handling and operations-budget review. Work one section per module, building each piece in your real Make account as you go and filling each worksheet. By the end you will have a small library of live, documented scenarios with the error handling to run them unattended, instead of a pile of fragile half-built automations.

Inventory your repetitive tasks, pick the cheapest high-value one, build it as a two-module scenario, and set a schedule that fits the job and your operations budget.

For one week, list every repetitive app-to-app task you do by hand, then score each for automation fit. This is the most important input to the whole project, because it tells you which glue work actually fills your day. Do this before building anything.

Pin down the smallest useful version of your first automation before opening the canvas. Keep it to a trigger plus one action so it is cheap to run and easy to debug. Fill this out and build exactly what it describes.

Estimate the monthly operation cost of this scenario before you turn scheduling on, so cost is a design decision rather than a surprise. Compare the result against your plan allowance and adjust the schedule if needed.

Map the right fields with the right types, transform messy values with built-in functions, and add early filters so only qualifying records cost operations.

Run your scenario once with real sample data, then walk the mapping panel field by field to verify each mapped value lands in a field of the matching type. Most beginner failures are type mismatches, so find them here before they break a live run.

For each value that arrives in the wrong shape, plan the function that fixes it in transit. Test each one against the live preview in the mapping panel before saving. Reuse this whenever a destination app rejects your data.

Place a filter as close to the trigger as possible so unqualified bundles stop before any expensive work. Test with records that should and should not pass. A bundle stopped at the first line costs nothing; one stopped at the last wasted everything before it.

Design routers that send records down the right path, iterators that process every item in a list, and aggregators that fold many items back into one clean output.

Plan each branch of your router as one clear question about the record, with its own filter and purpose, before building. Order specific branches first and a catch-all last. Keep this beside you while you wire the router.

Take a real list field, such as order line items or email attachments, and unpack it with an iterator so the modules after it run once per item. Watch the operations multiply and decide whether you need every item. This pattern handles most list-shaped business data.

Use an aggregator to turn many bundles into a single combined output, such as one summary email instead of fifty. Getting the source module right is the part beginners miss, so test that the combined output contains every record.

Add error handling that retries or recovers, switch to webhooks and the data store where they fit, watch the operations budget, and document each scenario for handoff.

Decide in advance how each fragile module should behave when it fails, so a single bad record or brief outage never silently stops the automation. Match the directive to the situation, and always add an alert for failures a human must see.

For each scenario, choose between scheduled polling and an instant webhook, and decide whether it needs a data store to avoid double-processing. Webhooks give speed; the data store gives memory. Test the deduplication so the same record is never handled twice.

Document every scenario so the system survives handoff and the 3 a.m. failure. Fill one row per scenario and keep this inventory current; it is the first thing a teammate or future-you will need.