Weird But Useful Make.com Features Solo Builders Should Watch

1. Scenarios fail silently when you rename variables mid-flow

I made the mistake of renaming a variable in a Make.com Router branch after it had already been used downstream in a few filter conditions. At first, nothing looked broken. No red modules. Filters stayed green. The scenario even executed without an error—but none of my routes triggered after that change. Took nearly an hour to spot the inconsistency because there was no visual error and re-saving didn’t prompt anything. Make doesn’t always revalidate filters when variable names change post-facto. And if it evaluates to a blank field instead of throwing an error, it just quietly fails the condition.

If you edit a variable name:

• Re-check every router filter that used the original name
• Watch expressions in Set Variable modules—those don’t update dynamically
• If you’re using bundles.map() or get() within an iterator, verify references directly in the raw JSON layout

Eventually I dropped in a raw {{JSON.stringify($)}} logger right after the router to dump bundle content. That was the moment I saw undefined where the variable used to be. Massive facepalm. If you’re curious, this behavior doesn’t seem to show in simple filter tests—but in production, those ghost references crash logic without crashing the scenario.

2. Webhooks requeue if the Make scenario is updating quietly

If you push a live Make scenario update while an active webhook is mid-run, some calls won’t fail—they just stall and retry later. I had a Calendly → Notion → Slack multi-tool setup where the webhook passively retried several times because a module was being dragged around and resaved in Make. Kind of shocking, honestly. It turns out that Make lets previously set up webhooks queue incoming POST traffic even while the scenario is being re-versioned. That would be thoughtful—except there’s no visual indicator, just a delay that gives false hope.

Documented? Barely, and misleadingly

The docs say webhook URLs remain active across edits, but they never mention you might get race conditions if an edit overlaps with traffic. Turns out the queue doesn’t persist if you delete the webhook module and re-add it with the same name. Learned that the hard way. Also, the webhook queue seems to drop anything after five back-to-back 500 responses. But no 429 warning, no event log.

3. Filters sometimes cache a condition until you hit Save twice

One of the weirdest bugs I’ve hit: Make filters can hang on a previous state if you edit their expression but never toggle the module off/on or re-save the scenario twice. During a client build last month, I changed a filter’s regex pattern to be more restrictive, tested the updated string using the built-in test utility, and it matched fine. But when live data ran through it? Still passed bundles that shouldn’t have matched.

I walked away and came back. Resaved. Then toggled the filter off manually and back on. Only then did the new pattern kick in. It’s inconsistent, but it usually happens when the edit was done via double-clicking the filter condition (not the pencil icon). It’s like the visual editor temporarily caches the string without syncing it to execution-time logic.

So if you’re editing filters in-place and something isn’t working: re-save the whole scenario, not just the one module.

Minor detail, big waste of time.

4. Execution history lies if a JSON response gets truncated

This one is gnarly and almost wrecked a whole CRM sync for a financial solo founder I was helping. Make truncates incoming JSON logs in the Execution History UI—but it doesn’t tell you it’s truncated. If your HTTP module receives a payload that’s too large (maybe a deeply nested object or thousands of rows), you’ll only see the first chunk in the visual debugger. And if an error happens later in the array, good luck spotting it without a manual log-to-array parser.

Real world impact:

I had a module grabbing Airtable records via the API, parsing them with a custom aggregator function. Execution Logs only showed the first maybe 60 rows. But Sheet syncs kept throwing null values in row 78. I manually dumped the body into codebeautify.org and finally saw the empty field with an unexpected “float” key tucked under an optional array property.

So now I always add a Write to Google Sheets step, pipe the full JSON as a raw string, and check it from there. Bonus: you can filter newlines and sections using Google Sheets regex.

5. Make support gives different answers than same-page tooltips

This is something subtle but it affects solo users without dedicated dev teams: Help tooltips inside Make sometimes directly contradict support reps. Like—literally. Check this out. The tooltip for a scheduling module said, “Minimum interval time: 1 minute.” I set it to every 2 minutes. But when the webhook only ran every 4–6 minutes, support told me the minimum is 5 minutes unless you’re on a higher plan.

Tooltip: “Minimum interval time = 1 minute”
Support: “2-minute intervals may be queued depending on server load unless you’re on Pro+”

So yeah. The UI doesn’t adapt to plan limitations unless you manually trigger something that fails. There’s no warning pre-save. I ended up restructuring the flow into a webhook-triggered path with fallback cron-based polling every 10 minutes, just to guarantee throughput. That workaround alone cut four failed syncs per day. Would’ve saved me hours if that had been consistent in-app.

6. Scenario cloning does not clone webhook authentication settings

If you clone a Make scenario that includes a webhook module, don’t assume the webhook secret or criteria travel along with it. I had a Stripe flow that triggered when a charge.succeeded payload came through. Cloned it to set up a test environment and got HTTP 200s but no scenario execution. Turns out the cloned webhook kept the same endpoint URL, but dropped the Shared Key auth setting from the original.

So if Stripe sends over a signed payload, and the scenario expects a shared secret that no longer matches—it gets the payload, but ignores it. No visible error. Green light lights up. Nothing runs. That was three hours of cursing and re-reading logs before I narrowed it to the API section, not the webhook config.

What fixed it: delete the webhook module inside the clone, re-add it fresh, then the Shared Key section shows up again. Copying/pasting across modules doesn’t inherit those hidden configurations either.

7. Unexpected behavior locking Arrays inside a Switch module

This might be a Make quirk or a JS thing leaking through—but nesting an array operation within a Switch condition sometimes breaks in scenarios that auto-merge bundles. I had this build where a list of product SKUs needed to be routed based on source. Used a Switch module to branch by origin tag, and within that, grabbed bundle["lineItems"] expecting an array every time.

But every now and then, the scenario threw “Not an array” even with correct formatting upstream. The Switch condition locked the data shape mid-scan, and any dynamic output from upstream collection formatting wasn’t injected in time to be evaluated.

Putting the array parser before the Switch module solved it immediately.

Lesson: don’t nest iterators or array-generating logic inside Switch branches. Make sometimes evaluates Switch inputs before completing bundled merges, especially if a previous module has “Map merged items” enabled.

8. Manual execution tests can hide unstable timezone logic

Timezone gaps are a nightmare if you’re solo-building for asynchronous teams. I had a Notion scheduling bot that converted submission times from various regions into one synced timeline using the Set Variable module and Now.format(). What I didn’t realize is that manual test mode in Make runs with the browser’s local timezone—so during build, I was correcting times that later came out wrong on live runs, because production ran on Make’s European servers at UTC.

Make doesn’t warn you. The output JSON even labels time zones inconsistently. One example from my logs:

"created": "2023-08-03T14:22:00+02:00", vs. "timestamp": "2023-08-03T12:22:00Z"

Moment.js stuff falls apart fast if input zones vary like this. What worked better: explicitly offset using dateadd or dateshift before formatting. Also, run the test scenario using an always-on Webhook trigger rather than Manual Run mode to see the server-side perspective. I keep a ping URL in Notion just for this—tap to simulate incoming data without touching the browser.