WhatsApp automation

Hire a Pro Hire Help
,
1

I’m building a WhatsApp automation using Make.com, TimelinesAI, Airtable, and OpenAI.
The goal is to create a reliable, production-ready scenario that can later be duplicated.

Build a clean and robust Make scenario that:

  1. Receives incoming WhatsApp messages from TimelinesAI

  2. Creates or updates a Prospect record in Airtable

  3. Stores conversation data consistently

  4. Sends AI-generated replies back via WhatsApp

  5. Avoids fragile logic (Record ID loss, router issues, bundle breaks)

  6. Is easy to duplicate for other clients (same structure, different bases)

:brick: Current Stack

  • Make.com

  • TimelinesAI (WhatsApp integration)

  • Airtable (CRM – Prospects table)

  • OpenAI (reply generation)

:police_car_light: Where It Currently Breaks

  • The scenario becomes unstable around Airtable record handling

  • Issues encountered:

    • Record ID dependency causing failures

    • Router breaking bundles

    • Inconsistent behavior between Search / Update / Upsert

  • I need a clean, deterministic approach that does not randomly fail in production

3 Likes
3

Hello @Judith_Louis , welcome to make.com community, I have worked and have experience with Make.com and l will love to collaborate with you on this you can schedule a call Here and you can checkout my upwork profile Here, for my pastworks and certifications

4

I see you’re aiming for a production-ready WhatsApp automation that’s stable, deterministic, and easy to duplicate, and the main issue right now is fragile Airtable record handling in Make.

I can rebuild the scenario with a clean structure that avoids Record ID loss, stabilizes search/upsert logic, and prevents bundle breaks around routers. The focus will be predictable record resolution, consistent conversation storage, and reliable OpenAI replies via TimelinesAI.

If this sounds right, I’m happy to clean it up and make it truly duplication-ready for other clients.

I’d like to have a chat with you regarding this. scehdule a call with me here to discuss this

5

Hey @Judith_Louis,

You’re letting Record ID float around when it should be locked down immediately. That’s why it breaks in production.

Use the phone number as your source of truth. Search Airtable by phone first. If you get a record back, grab the ID. If nothing comes back, create the prospect and grab the ID from the response. Store that ID in a Set Variable right away and reference it everywhere downstream. No more ID loss between modules.

Ditch the routers. They’re adding fragility. Instead of branching on whether a record exists, use one If module after your Search step. One path creates, one path updates. Both feed the same downstream flow. Simpler, fewer places to break.

Split conversation storage. Don’t cram the full message thread into one Airtable field. Create a separate Conversations table and link it back to the prospect record. One prospect, many conversation rows. Way easier to debug when something goes wrong, and it scales better as volume picks up.

Avoid Upsert. Search + Update is more reliable. Upsert is a black box and you never really know if it created or updated, and the response is inconsistent. Search tells you exactly what happened.

The flow ends up looking like this: webhook > search by phone > store ID in variable > if exists then update else create > same downstream modules for both paths > create conversation record > call OpenAI > send reply.

Copy that scenario to a new client base, swap out the Airtable connection and WhatsApp numbers, and it just works.

I’ve built a few of these in the past. Looking forward to working with you!

6

Hi Judith :waving_hand: Welcome to make.com community.

This is a very solid stack, and the issues you’re describing are classic Make + Airtable instability problems when scenarios aren’t designed deterministically from the start.

I specialize in production-ready Make.com automations (especially WhatsApp + CRM + AI flows), and I’ve built duplicate-safe scenarios exactly like what you’re aiming for.

How I’d approach this (clean & reliable):

1. Deterministic Airtable handling (no fragile Record IDs)

Use a single unique external key (e.g. WhatsApp phone number or TimelinesAI conversation ID)

One Search → conditional Create/Update pattern

Never pass raw Record IDs across routers

Centralize Airtable logic in one place only

2. No bundle-breaking routers

Minimal routing

Logic handled with filters + variables instead of routers where possible

One message = one controlled execution path

3. Stable conversation storage

Append-only message logging (no overwrites)

Consistent schema for inbound/outbound messages

Easy to replay or audit conversations later

4. AI replies that won’t break the flow

OpenAI called only after state is resolved

Guardrails for empty / duplicate / system messages

Clean handoff back to TimelinesAI

5. Duplication-ready architecture

Same scenario structure

Swap Airtable Base ID + API keys only

No hardcoded IDs or client-specific logic

Documented setup steps for future clients

Outcome

You’ll end up with:

A stable, production-safe WhatsApp automation

Zero random Airtable failures

A scenario you can duplicate confidently for other clients

Clean documentation for scaling

If you’d like, I can:

Audit your current scenario and refactor it

Or rebuild it cleanly from scratch using best practices

Happy to review screenshots of the current setup :+1:

7

Hi @Judith_Louis,

With over 5 years of experience in automation, reliable production ready workflows are built using Make.com, Airtable, and OpenAI. Strong hands on experience includes designing WhatsApp automations with TimelinesAI that avoid record ID issues and unstable logic.

The focus is on clean, deterministic scenario design that ensures consistent record creation and updates, reliable conversation storage, and easy duplication across multiple clients.

Happy to help build a stable and scalable solution for this use case. You can view the Fiverr profile or connect on LinkedIn. Also available for a quick call to discuss requirements.