Weird Automation Workarounds Used by Startups Every Day

Weird Automation Workarounds Used by Startups Every Day

ByUS Stacked

1. Forwarding emails just to extract the same three fields

You’d think that by now Gmail or Outlook would let you consistently grab structured data from invoice emails. They kind of do — until your CFO changes the invoice format without telling you, and now your filter or Zap stops catching the amount. I had an Airtable auto-logging setup that used “New Gmail label added” as a trigger, then extracted amount, vendor, and due date using Zapier’s Parser. Worked great… until some genius added an image to the invoice footer. After that, the body parsing failed silently — no error in Zapier, just empty fields in Airtable without warning.

There’s no built-in fallback behavior for semi-structured parsing like “if amount not found, check signature block.” You can use GPT or Claude to parse the email body, but then you’re introducing another layer. Also, Claude’s API isn’t natively integrated in anything, so now you’re piping email → Zapier webhook → custom OpenAI call → back to formatted webhook → Airtable.

Minor edge case I hit: one client had their accountant reply to every invoice email with “Paid” — which also triggered the parser. So I had to filter by subject line AND timestamp proximity to invoice date. Google’s filters don’t expose that kind of logic, so I added a Make.com router path with a window of two hours before creating a row. Hacky but worked.

If vendor = Stripe and amount field is null, check body for `$` followed by a number, then validate it’s within last 60 days — my GPT prompt literally said that. Ugly but reliable.

2. Using Google Sheets as a timeout loop for delayed actions

Zaps don’t wait. They do things now. But sometimes you don’t want a follow-up email until a contract has sat unsigned for a few hours. Yeah, delay steps exist — but Zapier’s built-in Delay still isn’t context-aware (as of this writing anyway). So I did what most American startup folks quietly do: drop timestamps in a Google Sheet and poll it later.

Here’s the trick: Zap A logs the event (say, uploading a sales agreement) into Sheet with a status column. Then every 15 minutes, a scheduled Zap looks for rows where status = “waiting” AND timestamp older than 3 hours. If true, it fires step two (like sending a reminder email) and updates the status to “closed”.

Real snag: Zapier’s “New or Updated Spreadsheet Row” trigger isn’t reliable for multiple edits in short bursts. The Zap misses intermediate row changes if they occur fast. I could see it directly in the task history — it just skipped a row update entirely under load. I had to switch to Make.com’s Google Sheets “Watch Rows” module, which allows parameterized polling by last-modified column. Much safer, if a bit fiddly.

Pro tips if you’re doing this:

  • Use UNIX timestamps, not formatted date strings
  • Include a GUID or composite key so you can dedupe in downstream systems
  • Sort by oldest-to-newest rows before filtering
  • Set limit to 50 rows or you’ll get rate-limited fast
  • Time-based logic like “older than 3 hours” should be done inside scripting, not filters

Delay Until is a tease unless you control all downstream kickoffs. Nobody does.

3. Wrangling Slack thread replies into Notion without duplicates

Slack threads are useful but hell to automate around. You get a message → someone replies → maybe someone else reacts → and now you want the whole thread copied into Notion as a page. The obvious problem: Slack sends each reply as a separate event. Zapier doesn’t aggregate them. So if you trigger on “New Message in Channel” with thread replies included, you get… a bunch of notifications. Not the full thread.

What I ended up doing (and what worked 80% of the time) was capturing the thread_ts as the grouping key. Then a Zap would delay itself 5 minutes, fetch all messages using Slack’s API with `conversations.replies`, then dump that array into a Notion database field.

The bug: Slack randomly drops `thread_ts` on the parent message if replies are bot-generated. One client’s internal alerting bot used incoming webhooks, and its messages didn’t register as threads correctly. As a result, the replies never got grouped, and Notion pages had orphaned comments. Only fix was to force every bot post to include `thread_ts` artificially, which you can’t do in Slack UI — only from the code-side webhook payload.

thread_ts: event.thread_ts || event.ts

This one line in my Node webhook rewrite saved hours of chaos. It just assumes the top-level message timestamp is the thread_ts unless overridden. Works because Slack treats the original message’s ts as the root of reply threads — unless it’s broken.

4. Filtering Airtable views dynamically inside Make scenarios

Airtable’s API is legible but has caveats. Their internal filter formulas aren’t completely documented in the API reference, so when you try to filter a view based on, say, TODAY() minus a date field, it behaves… mostly right. But not entirely.

I needed to build a follow-up email system that checks if an “Onboarding Completed” checkbox is still blank 7 days after “Signup Date”. Sounds simple. In the Make.com Airtable module, I filtered by view. That view used this formula:

AND(NOT({Onboarding Completed}), DATETIME_DIFF(TODAY(), {Signup Date}, 'days') >= 7)

This returned no results. The Airtable web UI showed five matching rows. Turns out the TODAY() function resolves at a different time in the API than in the UI — it lags by about 15–45 minutes sometimes. Confirmed by checking the raw record JSON returned by Make vs what was visible in the UI. Lovely stuff.

Fix was to move the date diff logic into Make. I fetched all records where Onboarding Completed = false, then filtered them in a code module using Make’s ISO date functions. Still feels wrong though. The UI says one thing, your automation runs another.

5. Notion database relations randomly fail in synced Zapier loops

The newer Notion API lets you relate databases with relation fields — so you can, say, create a Deliverables record and link it to a Project record. Neat. Except: If that Project was just created in the same Zap, that link sometimes silently fails. No error, no visible bug. The Deliverable gets made, but the relation to Project is null.

This happened maybe one in five runs. Only way I caught it was by eyeballing Notion and seeing orphaned deliverables floating without a connected project. After MUCH digging, turns out newly created Notion records take a few hundred milliseconds to become referenceable in subsequent API calls. Zapier doesn’t wait. It just fires the second POST immediately and Notion says “cool” — but silently drops the link.

What worked better:

Using a zap delay of 4 seconds (literally a wait step with 4s) between the Project creation and the Deliverable creation. That’s dumb, but it worked. Make.com let me add a conditional loop that pings the Project ID until the lookup returns a name instead of null. Took about 1.2s average. Honestly cleaner.

Also had to switch from title-based relations to direct ID-based links in Notion. If you use titles, they must be unique, and if someone renames them later, the relation breaks invisibly.

“relation”: [{ “id”: “baf4301c-9b1c-4b34-b2a7-xxx…” }]

Notion accepts this format only via API. The UI shows it fine but doesn’t help you construct it. You either pull that ID on creation or never reference it again.

6. ChatGPT randomly rewriting numbers inside pasted invoice data

I had a workflow where someone would paste a paragraph from a PDF invoice into a webform, which triggered a Zapier webhook → passed to ChatGPT → parsed as structured JSON → saved to Airtable. Mostly worked. Until it didn’t. We started getting amounts like “$396” rewritten as “$360” — the model was interpolating based on guessed logic, not text fidelity.

This was with a GPT-3.5-turbo endpoint, using basic instructions like: “Extract vendor, amount, and due date. Output JSON.”

Turns out if the input paragraph isn’t wrapped in triple backticks, the model applies random token-level compression. Numbers are especially vulnerable. For example:

Invoice: XYZ Corp
Total Due: $396.00
Due Date: April 29, 2024

became

{
  "vendor": "XYZ Corp",
  "amount": "$360",
  "due_date": "April 29, 2024"
}

Completely invented amount. I switched to this prompt format:

Parse the following raw text as-is:
```
{invoice_body}
```

Fix rate went from 70% to 98%. And yes, Claude handled this better out of the box, but no native Airtable integration.

I wish models respected numerical fidelity the way they do dates. But they don’t.

7. Broken fallback logic in Zapier paths with missing Router matches

Router paths in Zapier are supposed to be clean. Add a condition. Match X equals “web signup”? Go down this branch. Else? Continue elsewhere. Except if none match, the fallback path ends the Zap with an error… unless you explicitly add a “Catch all” action. The catch is there’s no visual cue when that fallback gets skipped. No run history, no log, nothing — it just fails silently.

I encountered this in a customer welcome flow where form type determined the onboarding link. Roughly:

  • If source equals web-form-new, use path A (send email with link A)
  • If source equals partner-signup, use path B (send email with link B)
  • Else…? Nothing was defined.

So when we added a new form last month and forgot to add a matching router path, the whole onboarding sequence just failed. Took three days before someone noticed no new users onboarded. Not cool. Solution was to add a dummy fallback route that sends an internal Slack alert — and logs a row in a “Zap Errors” sheet. Took five minutes. Shouldn’t have taken three days.

Zaps don’t do dry runs. They either fire or fall through. Always build a fallback route explicitly — even if it’s just an Email to self with {source} and {timestamp}.