When clicking Save does not actually save
So I’m in this shared Zap, right? We’re tweaking a trigger to fire only when the new record in Airtable has a status of Approved. Simple. Filter by Status field equals Approved. I add it. Hit done. Click back. Then check the history.
Nothing. No new runs. Weird.
I save again, triple check everything. And that’s when I notice something — weirdly, clicking Save doesn’t always mean Zapier actually saves the new logic. It might say it’s saved. The UI shows the change. But if you return later, your filter step is staring back with the *previous condition*.
Turns out, *if you’re editing a shared Zap started from a template or Team folder*, changes made to a Filter can fail silently. I only figured this out when I duplicated the entire Zap into My Zaps and re-added the same filter logic — boom, it started working. ¯\_(ツ)_/¯
Why Make scenarios break when adding new modules
One thing about Make (formerly Integromat) is that it’s very visual. You’re watching bubbles connect to bubbles. It feels like building a neural map 🙃 Until you add a new module in the middle… and everything loses its mind.
So we had a simple Scenario running: Google Sheets ➝ filter ➝ Gmail
We wanted to add one extra step between the filter and Gmail to enrich the data from an internal API. Seems like a harmless addition. I inserted an HTTP module, set it to GET, mapped the Sheet data into the query param.
Ran a quick test. The HTTP step worked.
But — suddenly, Gmail was getting null values.
What happened?
In Make, inserting a module re-indexes all following paths. So all `1.value` references might now become `2.value`, or `3.value`, depending where they’re coming from. And unless you go in to *every* downstream module and *manually reselect the updated paths*, your existing field mappings can silently break without warning.
No validation. No notice.
Just broken emails that said: “Hi , here is your update.”
😑
Where Zapier Teams run into workflow permission collisions
You’d think Teams makes things easier. And honestly, it does — until you’re working in someone else’s Zap and get stuck with this wildcard:
You have permission to edit the Zap, but not permission to *reconnect* the app because it’s linked to a teammate’s credential.
So you’re editing a Slack step, right? Want to switch the channel. You pick a new one. Error: “This action requires access to the connected Slack account.”
Okay fine. You try to reauthorize. Nope. Greyed out, only the original owner can do that.
So the workaround is:
1. Duplicate the Zap to your own folder
2. Remove and re-add all steps requiring reauth
3. Reconnect *your own* Slack
4. Rebuild all data paths that used the old connection
Oh and if you forget to re-map a field? The Zap still passes validation, still turns on, but your messages just… don’t go anywhere.
Make doesn’t entirely fix this either — their scenario ownership is just as annoying. Only the original creator can edit blueprint-level settings like scheduling or webhook tokens. You can clone, of course, but now you’re managing *two separate Scenarios* with almost the same name. 🙃
Filtering by time ranges on Make is not human logic
We had one Scenario fetching new deals from Pipedrive every 15 minutes. It uses a search module like “Get new deals where added_time is after last_scenario_run.”
But data kept going missing. Not late, not duplicated. *Completely skipped.*
Eventually, I realized: Make’s date filters use ISO time *as strings*, not as actual Date objects. So if Pipedrive returns `2024-05-06T10:15:00Z`, and the Scenario last ran at `2024-05-06T10:15:01Z`, Make searches with a strict `greater than` logic — meaning anything at exactly `10:15:00` gets ignored.
Cool cool cool.
So what’s the fix? Add a buffer.
We added a DateTimeMinus step subtracting 1 minute from `last_scenario_run`. Even if it gets duplicates, we dedupe them later. Because missing data is worse than duplicated data. Always.
Zapier does something similar but less transparently — when you use Delay Until or Schedule/Delay by Zapier, the rounding behavior can backfire. For example, scheduling something at “Tomorrow at 8am” might actually trigger at 7:59 if your timezone is off. It’s not consistent. It’s barely even testable.
Webhook payloads that sneak in invisible nulls
One of our Zaps listens for a webhook fired by an internal service every time a new support ticket is created.
Sample payload looks like this:
{
“ticket_id”: “xyz123”,
“priority”: null,
“created_at”: “2024-06-01T12:30:00Z”
}
We built a filter step: Only continue if `priority` is not null.
Guess what? Zapier says the filter passed, even when `priority` is null.
Turns out, the null coming from our webhook isn’t a pure `null`. It’s actually an empty string or a space — it depends on how the payload was built.
So we had to rewrite the filter to this:
– Text > Does not exactly match > (leave blank)
– AND
– Text > Does not contain > “null”
Even then, our formatter step threw an error randomly 1 out of 20 times. The workaround? Add a Code by Zapier step that replaces `null`, “null”, and ” ” with a fallback string like “medium”. Then pass that forward consistently.
Over in Make? Slightly better. You can set strict null logic in conditions. But the UI has this fun habit of turning invisible characters into actual input accidentally. Like if you paste in a space thinking it’s blank? That’s now string length 1, which messes up your conditions silently 😐
Zapier file uploads that fail silently
So you’re running a zap where uploaded files from a Typeform response need to be sent via Gmail.
You get the form entry, grab the File Upload field. You see the URL — looks valid. You add that URL into the Gmail attachment field.
No error.
But then — the email sends with zero attachments.
Why?
Zapier doesn’t auto-download URLs for attachments unless they end in a file extension. And Typeform file links? They’re redirecting shortlinks.
So even though the test shows the file URL, Gmail treats it as empty or invalid. You won’t get an error either because the step executed successfully.
Short version: you HAVE to pass it through a Webhooks by Zapier GET step first. That step downloads the file, and you map the raw `file` output into Gmail. Only *after* that will it show up as real attachments.
Same behavior on Slack uploads too. And just to be extra annoying, Make requires a very specific `data:binary` structure and file name together, or the upload fails but still shows a green checkmark 😅
Unexpected auto-conversion of booleans breaks spreadsheets
This one nearly wrecked an entire Monday.
We’re sending task updates from Asana into Google Sheets with a Zap. One column is “Completed”. So we map `{{task.completed}}` thinking it’ll be TRUE or FALSE.
It is. For a while.
Then one day — half the column shows “true”, others show “TRUE”, and some cells are just blank. WTF.
Google Sheets interprets strings case-sensitively in formulas. So if you try filtering by TRUE, the rows with “true” won’t match. And if the cell is blank because the key didn’t exist (e.g. task not completed yet), your row gets silently skipped in logic.
Fix? Formatter step. Always cast booleans to uppercase string yourself. Then add default fallback:
– If task.completed is true → return “TRUE”
– Else → return “FALSE”
Then you never deal with blanks.
Oh and yes, Make does this too. But with bonus chaos: if you use JSON module, true and false get stringified based on the module *before* it. Meaning one path gives you raw bools, another gives you strings saying “true”.
Handling scenario loops in Make without infinite fails
We had one Make loop that processed items in a list — say, multiple line items in an order. The data came from a webhook request with nested data:
{
“order_id”: 123,
“items”: [
{“name”: “Widget A”, “qty”: 2},
{“name”: “Widget B”, “qty”: 1}
]
}
In Make, you use an Iterator to loop over these. We set it up. Watched it run.
But randomly, the entire Scenario would error out with “invalid data structure” — all because once in a while, some orders had *empty* `items` arrays. Which meant the Iterator had nothing to work on, and Make threw an error.
So we added a Router. Route 1: if count(items) > 0, go to iterator. Route 2: default, do nothing.
Now when an order has no items, it exits quietly. Took us way too long to realize that an empty list isn’t the same as a missing field in Make. They’re handled very differently.
And in Zapier? You’d need to use Looping by Zapier, which still doesn’t support nested arrays well and can silently fail or loop only once if the data isn’t flat enough.