Small Business Automations That Break Until They Finally Work

1. New lead emails that send twice or sometimes never

This one tripped me up right after adding a simple Zap: when a new lead comes into Webflow (via form), Zapier should send a notification email to our team Slack and another to the sales inbox. Sounds easy. But Slack notifications were showing up twice, and the email wouldn’t come at all. No errors, just… silence.

The Webflow trigger was firing twice — once on submission and again on some internal save event. The duplicate payloads looked identical unless you scroll in Zapier’s task history and notice tiny timestamp differences. Nothing in Zapier’s editor warns you about this. The only workaround was filtering by a hidden input name I had to add underneath the form just to identify “triggerworthy” submissions. Not ideal.

Also discovered this: if you’re using Gmail as the action and send to your own domain, those messages don’t always show up right away… especially if you reply inline. I was chasing phantom emails for 20 minutes before realizing they had threaded themselves silently into an unrelated chain.

2. Google Sheets automation breaking when someone renames columns

If you’ve let anyone else on your team touch the main contact intake sheet, there’s a good chance Zapier broke and didn’t tell you. Renaming a header from “First Name” to “First name” is technically different. Especially if the zap uses the human-readable field names instead of column letters — which it does by default.

I found this out when a zap silently stopped grabbing email addresses from the sheet, because someone added a note to that cell which quietly shifted the whole column structure. The column IDs hadn’t changed in the backend (the A1, B1 stuff stayed stable), but the linked field name inside Zapier lost connection. No warning, no failed runs — just null values quietly populating our CRM.

Tip: Always capture both the column letter and original header, especially if your team likes to tinker.

• Never use “first row as headers” unless headers are locked
• Create another hidden sheet Zapier reads from
• Use a FIND function to normalize field lookups
• Push safe data only using FILTER or QUERY functions
• Set up a weekly check for blank field submissions

The worst part? Google Sheets doesn’t log structural edits clearly unless you’re inside version history — which no one checks unless they’re fighting fires.

3. Airtable webhooks delayed for 45 minutes after new record creation

This one almost made me ditch Airtable entirely. A webhook triggered by “New Record in View” would sometimes fire instantly. Other times — no joke — it took over 40 minutes to send. I watched it happen repeatedly after enabling verbose webhook logging through n8n. No pattern, no error emails.

Turns out: views that use conditional filters based on calculated fields (like formulas or rollups) don’t refresh predictably. If there’s even a slight debounce window or calculation lag, Airtable caches that record as not present in the view… until its sync loop randomly re-evaluates it.

Not documented anywhere, obviously. My workaround was to trigger via “Record Created” first, then run a second filter step in n8n that mimicked the view logic. Way less elegant, but at least dependable.

{
  "event": "record.created",
  "record": {
    "Name": "Jenny",
    "Score": "Pending"
  }
}

The quote that clued me in came from the Airtable forums (buried, five years old): “Views aren’t updated in real time on the backend — it’s closer to CRON than live trigger.” Once you hear that, half the weird behavior starts making sense.

4. Slack actions randomly failing inside Zapier after emoji rename

I only figured this one out because someone on the team changed our “:check:” emoji to a custom one with the same name, and suddenly every Slack automation that reacted to messages with that emoji just broke. Not errored out — silently failed the action step. Those automations didn’t even get flagged in Task History.

The issue: Zapier caches the emoji ID behind the scenes. If the custom emoji slug points to a different image or ID now, the action step fails in a way Zapier doesn’t report because technically “nothing” happened. The API call completed — it just didn’t do what you expected.

If you ever change any emoji name, re-test every reaction-based automation manually. Yes, all of them.

Also fun fact: replying to a thread in Slack via Zapier’s “Send Message” action doesn’t notify participants unless you also pass the original timestamp as “thread_ts” and use the “as_user” flag carefully. Default behavior silently drops the comment in the thread without pinging anyone. Slack support confirmed this as “expected behavior.”

5. Calendly Zap not triggering if you edit the invitee afterwards

This one hurt because I was using it for onboarding. The Zap watches for a new Calendly event and auto-generates a Notion page with customer info. If someone reschedules or updates their email… the data passed in is sometimes partial. Occasionally the trigger won’t fire at all.

Notion data would populate with empty fields, blank phone numbers, or timestamps that didn’t match what the customer saw. I finally traced it down to this:

1. Calendly event created → Zap triggers correctly
2. User edits the event or reschedules
3. Zapier doesn’t re-fire the hook

This won’t show up in test data — which is always clean and static. You need to turn on Zapier’s auto-replay option and explicitly handle reschedules as a second trigger (like new Webhook or updated event flow). And good luck explaining that logic to someone else on your team who just wants a damn Notion page with the right details.

6. Make.com scenarios getting stuck when routers feed into HTTP calls

Very specific thing here — if you’re chaining multiple routers inside Make.com and one branch eventually hits a raw HTTP module, that module will sometimes lock the scenario if the payload isn’t exactly the type it expects. Especially with dynamic JSON structures coming from Webhooks or API calls upstream. The scenario doesn’t throw an error — it just sits in “Waiting” for hours, unless manually stopped.

I recreated this while debugging a newsletter content pipeline. User fills a form → goes to parser router → if longform, route to OpenAI summarizer → HTTP post to Beehiiv draft endpoint. The draft save step froze in 4 out of 10 cases. Turns out, one conditional flag (a Boolean) was sent as a string wrapped in quotation marks when the prior step generated it via text parsing — not explicitly mapped. HTTP module choked on that string, but didn’t fail.

The fix was to explicitly cast JSON values before passing them into HTTP — and yes, Make requires you to use toBoolean() or parseJson() manually. Their blueprint format doesn’t enforce expected schema downstream.

Quote from their team buried in a FB group comment: “If the HTTP payload isn’t malformed, we don’t throw. We trust the integration.” Cool. Bad idea.

7. Auto-generated invoices that skip customers without full addresses

This was unexpected behavior out of QuickBooks. A client wanted monthly auto-invoices sent to all active customers in a CRM where address fields were optional. But QuickBooks’ API accepts incomplete records — it just skips them silently if the billing address is missing. No task error. Nothing in outboxes. Just… no invoice ever created.

I used Zapier to bridge the CRM and QuickBooks, assuming the missing fields would just result in less data on the invoice. Nope. Turns out: if you pass an empty string for an address field but include the field name, QuickBooks’s API drops the entire request — and doesn’t throw an error. It considers it “non-submittable.” Even when test payloads show success.

My workaround was to pre-validate invoice payloads using a short Code step in Node to enforce a “minimum viable address.” Not shown in Zapier templates, but here’s a working snippet that rescued me:

const address = inputData.billingAddress.trim();
if (!address || address.length < 5) {
  throw new Error("Invalid address for invoice");
}

Still annoyed that the API says 200 OK and then drops the payload. But at least now I know which customers are about to get overlooked.