Beginner Workflows in Make That Actually Trigger Correctly

I’ve rebuilt this exact automation like six times, and I still don’t trust it to behave the same way twice. That’s just how Make behaves when it’s in one of its moods. If you’re new to Make.com (formerly Integromat) and trying to slap together a basic workflow, you’re not alone if things get mysteriously chaotic the second you hit “Run once”.

Here’s how I’ve learned—under fire, tabs crashing, modules erroring at 3am—to build a basic, beginner-level Make workflow that does what it says… most of the time 🙂

1. Start by picking a trigger that always fires

The devil is in the trigger. Most of my Make horror stories start when I mistakenly assume a trigger will consistently behave like a Zapier webhook. Nope.

For example: I once set up a Gmail “Watch emails” trigger. It refused to fire until I manually opened each email on the Gmail side. After about four hours and one support ticket, I switched to “Watch emails via search” with a custom query string (like label:mylabel), and only then did it begin actually picking up new messages.

If you’re just getting started, I sing the praises of these triggers because they tend to behave:

– Webhooks (custom webhook set up via the Webhooks module — super consistent)
– Google Sheets “Watch rows” (but filter down first so it’s not burning ops every minute)
– Airtable “Watch records” (bit slower, but generally dependable unless your base is huge)
– Email > “Watch emails via search” with a specific label (as above — DO NOT use the generic Gmail trigger)

Also, watch out for the silly bug where Make thinks a webhook has already been used. If you reuse a custom webhook that has sample payloads logged already, you might need to delete and recreate it to get fresh data. Sigh.

2. Add an initial test module that always passes

Seriously — just insert a JSON aggregator or an Array Aggregator or even a dumb Text > Set variable module immediately after the trigger. This gives you two things:

1. Reliable output to inspect when testing
2. One less thing to troubleshoot if the flow breaks midway

One day, I forgot to insert this buffer step and connected straight from an Airtable trigger to a Google Calendar module. Airtable returned a blank string in one field, which Calendar turned into an invalid date, which triggered a silent failure — the flow ran but didn’t do anything. ¯\_(ツ)_/¯

3. Always insert a router module earlier than you think

Routers are where I lose most of my time. They seem innocent until you run into a fork with two paths, and only one runs, or both run, or neither, depending on what Make decides it feels like that hour.

What works for me now:
– Route every conditional path separately with its own filter
– Write filter expressions in plain language first (in a Comment module) so future-me knows why I put in `{{1.value}} != “ABC”`
– Never assume data structures are the same between test runs — data from one router branch often doesn’t pass to another unless you explicitly aggregate it

Also, watch out for this one: if one route fails silently, Make will still report that the scenario ran successfully, even though nothing happened. This is maddening when testing because it all “looks green.”

4. Enable the auto-align washi tape mode for your modules

Okay, that’s not what it’s actually called. But you know the little “Auto-align modules” button in the toolbar? Hit that. Your future sanity during debugging depends on it. I resisted using it for too long and ended up with spaghetti that made zero visual sense.

One night, I was half-asleep drag-and-dropping modules and accidentally connected a conditional to an entirely wrong flow path. Since the wiring was diagonal and messy, I couldn’t tell until my Discord bot started sending invoices to the dev team groupchat.

Auto-aligned visuals = immediately clearer logic. Just do it.

5. Use the Data Store but mentally prepare for chaos

Data Stores in Make are like tiny databases-in-the-cloud, which is like giving a toddler a chainsaw if you don’t know how references work inside them. I love using them to temporarily store email addresses, API tokens, or timestamp snapshots — but when they break, it’s hard to know why.

One bug I repeatedly hit: If I store something with a blank key (or the key resolves to null), the store **swallows** that insert but never returns an error. Then when I try to retrieve it later, nothing comes out and the next module just fails silently. LOL.

If you’re using a Data Store:
– Always triple-check the key field with a Text > Set variable before sending it in
– Periodically flush the Data Store between tests — old junk can break your test flow
– Use Scenario runs to confirm the key is returning actual values

I also once had two modules writing to the same key simultaneously (because of parallel router paths), and the result was just… inconsistent overwrites that made the whole flow unreliable. Since then, I’ve used a Make function `{{round(now; 0)}}-{{randomText(5)}}` to build unique keys per run.

6. Don’t trust module mappings unless you’ve eyeballed all outputs

Mapping works beautifully until you run with a different payload than the one you tested with. For example: I had an email parser that sometimes produced extra fields when certain attachments existed. Those never showed up in my test run, so I didn’t map them. When a real user submitted an attachment-heavy email, Make failed with “Cannot read property ‘foo.bar[0].baz’ of null” — which isn’t a helpful message, Make.

So now I always:
– Export the raw JSON from the trigger module after multiple test runs
– Use the DevTools (yes, like in Chrome) to inspect what’s actually being passed between modules
– Or at minimum, insert a Text aggregator to dump all mapped fields into a string for manual inspection before the critical step

This catches structural weirdness you wouldn’t notice until someone feeds it a freak payload on a Tuesday. Which… has happened more than once.

7. Replace faulty modules with HTTP calls when possible

Sometimes a Make module just sucks. The built-in Slack, Notion, or Gmail modules do an okay job for simple APIs but start breaking down when you try to do anything beyond basics.

I once spent hours trying to update a Notion page with a checkbox toggle. Make’s Notion module refused to update the property unless I rebuilt the entire content block JSON manually. Eventually I just said screw it, wrote my own HTTP module with a direct PUT call to Notion’s API, and it worked instantly.

HTTP modules save you from these:
– Hidden rate limiting and lack of error messages (like in Gmail Send Email)
– Incomplete API support (e.g. Notion module still doesn’t support nested databases well)
– Poor dynamic field rendering (like Slack’s dynamic userID fields that crash when null)

Use HTTP modules if:
– The operation is failing but the API works in Postman
– You need more control over what gets sent
– You’re tired of mystery errors like Module 12 – “execution failed without error”

Also, in my Make error logs, that “execution failed without error” message usually means the module silently discarded your input or got confused by null mappings. It won’t tell you anything helpful unless you wrap it in Try-Catch, which– yes– Make technically supports, but only in the most awkward router-wrapped way imaginable.

8. Run once doesn’t mean runs ONCE

Here’s a thing: The “Run once” button in Make does not mean “run a single instance of this flow then stop.” It means “run this flow until it has no more data to fetch or process.”

If you use a Google Sheets Watch Rows trigger and there are three rows it hasn’t seen before, “Run once” will process all three. Weirdly, if one of those rows errors mid-scenario, the rest still process in the background — and the error may not even bubble up clearly.

To avoid this:

– Temporarily replace Watch modules with Webhooks during setup
– If you’re processing real data, use breakpoints inside your flow (via Filters that resolve false)
– Add a debug router early with a path that just logs the incoming bundle to a Notes module with an Alert

Seriously, I’ve sent automated Slack messages to clients during testing because I forgot to filter out actual airplane ticket receipts. Don’t be that guy 😛