When Business Automation Fails in Exactly the Dumb Way You Feared

1. Google Sheets formulas breaking when a Zap updates the row

If you’ve ever hooked up a Google Sheets + Zapier setup thinking “Oh perfect, I can just write some formulas in column G and let the Zap edit columns A to F,” prepare to lose three hours rebuilding something Google never intended you to do. The second your Zap updates a row—even if it doesn’t touch your formula column—Google Sheets may re-evaluate or straight up delete your formulas. I learned this during a client demo when a calculated discount value just returned #REF! on a screen share. Guess how well that went over.

The issue is deeper than it looks. Zapier’s “Update Spreadsheet Row” doesn’t preserve cell formatting or formulas by design. It sends the new values as an overwrite, and anything calculated locally gets flushed. Unless you stash your formulas in a separate sheet or rebuild them with array formulas referencing raw untouched data, Sheets won’t keep them around.

You can semi-preserve formulas by storing them as static strings and using Apps Script to re-apply them after update, but now you’ve bought yourself another set of problems. Mainly: Apps Script triggers run at unpredictable times unless explicitly throttled inside time-driven triggers, and debugging timing issues with triggers is basically 2007 JavaScript all over again.

Here’s what fixed it once: I pushed all logic into column formula patterns (like =ARRAYFORMULA(IF(A2:A<"", ...))) and made sure Zapier only added values in other columns. Never insert rows manually; always append. Relying on the row ID or row number guarantees a day when they don’t match anymore.

2. Notion automations deleting half of your context mid-Zap

This one hurt. I had a Notion + Slack notification flow set up where the moment a new action item got logged in a project table, the summary block in that same page would get appended with the task and assigned user. Except…suddenly, the page detail started cutting off everything after the second bullet. Cue five hours of Slack DMs asking why priorities vanished.

The root issue? Notion’s Zapier integration doesn’t play nicely with rich text edits via the “Update page content” action. If that content includes nested blocks or mixed formatting (like toggles or multi-level bullet lists), Zapier’s overwrite behavior turns it into a plain text paste. It doesn’t preserve structure. Worse, if your Notion database template includes hidden blocks (looking at you, toggle sections with subtasks), Zapier wipes them as soon as you push an update to the parent block.

If you want to insert content without destructive updates, use a child block creation instead, targeting the page ID and using the “Append block” action—not “Update page properties.” That’s the only way I’ve seen to reliably avoid nuking everything else in the page.

3. Airtable automations timing out without error when re-triggered

There’s a weird case that’s come up a few times when I’m using Airtable automations to write back into the same base. The flow is simple: new record is created → lookup related customer ID → fetch details → update record. The bug: if you retrigger the automation too quickly on the same row (like within 10 seconds), it sometimes throws…nothing. No failure, no log. Just skips silently. It’s like Airtable forgets you ever tried.

I’ve run into this most often when testing automations live while on calls, where time matters and you’re manually nudging records to re-fire. Turns out, Airtable has some undocumented internal caching windows where a record update won’t necessarily re-queue the automation unless certain fields are changed. Even then, if two similar updates arrive too close together, Airtable’s backend may discard the second without any record of attempt.

The workaround I found involves:

• Creating a dummy timestamp field (“Last reprocessed at”)
• Forcing that field to receive a new time value via a script action so it triggers a detectable change
• Using a script step to intentionally pause with await logic before rechecking field values
• Avoiding workflows that re-trigger on synthetic changes (like toggling a checkbox on/off quickly)

That dummy timestamp field saved me more than once—because once Airtable sees an actual datetime delta, it treats rows like new state changes again.

4. Webhooks silently failing due to missing trailing slashes

Midway through building a lead capture system using a webhook-to-CRM flow, I found myself chasing ghosts. We’d set up a webhook trigger in Make to call a CRM endpoint—API docs said the endpoint was https://api.ourcrmtool.com/webhook. Everything looked right. Until some submissions worked, and others just…didn’t show up at all.

Here’s the kicker: the API endpoint was sensitive to trailing slashes. So /webhook worked, but /webhook/ returned 200 OK with “no route defined for this exact path” behind the scenes. It never threw a fatal HTTP error. Just told us everything was fine while discarding the data.

There’s something deeply unsettling about systems that err completely silently.

That experience taught me to log every outbound request explicitly inside Make before it hits production. Enabling data store logs or webhook request summaries is priceless for tracing this stuff. Don’t assume green check = success.

5. Slack slash commands triggering twice when used inside a thread

This one I’m still not totally convinced is a bug or a feature. A client had a custom Slack slash command like /create-task, which piped task data into Asana. When used inside main threads, all was fine. But when used as a reply inside an existing message thread, two tasks got created—one with context from the reply, one with context from the parent.

Slack, it turns out, sometimes sends duplicate events when slash commands are issued inside threads. Depending on how the app is set up—especially if it uses context.message_ts vs context.thread_ts—responses can bifurcate based on which message you referenced. Some SDKs treat these as two valid triggers.

We worked around this by adding a deduplication hash of the user_id + timestamp to make sure that only truly unique interactions passed through. That meant storing each invocation fingerprint for about 30 seconds in our middleware and silently discarding repeats in that window.

Ugly? Yes. Reliable? Actually, yes.

6. AI prompt outputs changing randomly depending on surrounding JSON

This was a strange one: I had multiple Zapier + OpenAI prompts set up to generate subject lines depending on customer context. When I added a harmless extra key to the JSON payload—just a dummy "run_time": "now"—the tone of the subject lines changed. Same system prompt, same temp, same structure. Different feel entirely.

I reran it, toggling that extra field on and off four times. Identical parameters, different language. The presence of a non-influential field was enough to skew how OpenAI interpreted the rest of the payload. I haven’t fully reverse engineered it, but my guess is whitespace serialization or internal token ordering (alphabetical JSON reshuffling?) affects system-level embeddings enough to shift tone.

Debugged by logging full stringified inputs to a temp file on every run. Filtering diff between inputs showed that key order instability was real across systems that didn’t enforce canonicalization. If you’re generating prompts or building LLM microtools, make sure your JSON structure is frozen—and that your ordering is consistent before it hits the model.

Here’s the actual quote that confirmed it:

“Customer retention is our top priority. Take 15% off today!” → when JSON had 3 keys

“Because you matter — enjoy a loyalty gift on us.” → same prompt, same temperature, but five keys

7. Duplicate records from Tools like Tally not showing proper webhook uniqueness

For a while I was using Tally forms to intake demo request data into Airtable. Looked rock solid. But a few users clicked Submit—and then, after a delay, clicked again. Webhook fired twice. My Zap had no filtering, so two identical-looking records hit Airtable. We only noticed because one rep saw that two identical leads got assigned to different reps minutes apart.

Tally’s webhook trigger doesn’t include a reliable deduplication token (like a submission ID or UUID) you can use at the top of a Zap. The timestamp is close, but it’s not reliable in cases where someone refreshes and resubmits. You have to generate your own safe unique fingerprint—at minimum, combine email + source + timestamp rounded down to minute—and filter in Zapier with a lookup step to prevent illegitimate duplicates.

Also verify that your downstream tools (e.g. Airtable) aren’t auto-generating IDs that obscure the repetition. Use a temp “fingerprint” text field that logs each submission hash before taking action. I now store this value and reject any submission where it matches an existing record in the past 10 minutes.

That edge-case wasn’t documented anywhere—had to find it by literally building a dummy form and rage-clicking the Submit button five times myself.