Setting up an airtable base for posts
I always start with the Airtable base itself because if that’s wrong everything else collapses. The first time I set this up I literally didn’t add a “Status” field and wondered why I couldn’t track drafts vs published. I use a simple “Single select” field for that — Draft, Editing, Scheduled, Published — but the critical part is making sure you don’t accidentally choose “Multiple select” or your automation will fire for every option picked. I learned that one the hard way and Make ended up triggering three times for the same record 😛
The table usually has columns for Title, Slug, Body Text, Featured Image URL, Tags, and Status. I make another hidden field for “Last Modified” because Make triggers nicely off that in certain cases. Unless you’ve used Airtable automations before, be aware that Base permissions matter — if you have collaborators who can’t edit certain fields, Make will still see the update but it may not have the actual new data in the webhook payload. That’s one of those silent breakages that drives me nuts.
If I know I’m going to hook this into Make’s HTTP module, I also add a formula field that formats my record exactly the way my blog’s API likes to receive it — example: concatenating the Title and Body with a separator. Keeps the mapping pain lower later when you realize Make doesn’t like array of arrays for text blocks.
One thing I keep open in another tab when doing this is Airtable’s “Grid View” and a filtered “Today’s Posts” view. The filtered view is what I point Make to, so only posts with Status = Scheduled and a publish date of today make it into the automation. That trick saved me from waking up to see ten old test posts flood my live site.
Creating the trigger between airtable and make
There are a few ways to connect Airtable to Make, but for recurring blog workflows I almost always go with the native Airtable module in Make set to “Watch Records.” That way you’re not messing with webhooks unless you like pain. The gotcha here — and I swear this setting nopes itself without warning — is the “trigger on” field. If you choose “Created Time” it will only run for new records. If you later need it to run on edits too, you have to switch it to “Last Modified Time” AND specify which fields count as a modification. If you don’t, Airtable silently decides that none of your changes count as modifications and the automation just… sits there.
Once the trigger is there, add a filter step immediately in Make. I filter by Status = Scheduled so I don’t send drafts into my blogging platform. Without that, you’ll inevitably forget and accidentally publish half-baked posts. And yes, the first time I missed that, a half-written post called “test bananas” went live for about two hours before I noticed ¯\_(ツ)_/¯.
If you’re making the trigger check every few minutes, remember that Airtable’s free tier has API limits. If you hammer it too hard, your scenario will fail silently or go into a warning state with a tiny orange triangle nobody notices until three days later. I usually set my watch interval to something like every 15 minutes. For time-sensitive publishing, you can run it on demand instead.
Mapping fields to your blog platform
This is the step where messy Airtable data will trip you up. In Make’s mapping screen, your Airtable fields appear in a list with placeholders. The first mistake beginners make is dragging the Body Text directly from Airtable without stripping out extra line breaks or HTML weirdness. I run it through a “Text Aggregator” or “Replace” module in Make to clean it up.
For example, WordPress likes featured image URLs sent as a separate meta field. So in Airtable I store that in a plain URL field. In Make, I map that to “featured_media” in WordPress’s API module, but to do that I have to first upload the image to WordPress’s media library within Make, get the ID it returns, then use that in the post creation step. If you skip the upload step, your posts go live without images — no matter that you’ve added the URL in Airtable.
Tag handling is also a headache. Airtable will give you a comma-separated string of tags, but most blog APIs want an array of tag IDs. So I have a Make step that retrieves the IDs by name, then constructs an array before passing it to the publish module. The first time I didn’t, my posts just showed all tags as plain text in the body. If you’re not ready for API array work, you can skip tags until you have the basic workflow solid.
Testing the automation before going live
I can’t stress enough how scarily fast Make will push things live if you hook it directly to your publishing platform. My testing method is to swap out the “Create Post” step for a “Send Me an Email” step using Gmail in Make. That way, each time the scenario triggers, I get an email with all the mapped data in the body. This is how I caught an issue where my Body Text field was randomly missing the last paragraph — turns out Airtable had an invisible line break at the end of the field that cut off data in the API call.
I also watch the Make activity log like a hawk during testing. You can click into each run and see exactly what made it from Airtable to Make to the email. That’s where you’ll notice stuff like “Slug” being null because you forgot to fill it in for that record. The live test emails make it much easier to tweak mapping without blowing up your real blog.
Once it all looks correct in email, I duplicate the scenario, swap the email step for the actual publish step, and run it with a single real post. Then I immediately go back and put the Status filter in the first step if I somehow deleted it while tweaking other things (which happens more than I’m willing to admit).
Scheduling repeated blog posts automatically
Once you trust the workflow, you can make it truly repeatable by using Airtable’s date fields. I add a “Publish Date” field set as a Date type (no time unless your blogging platform cares). In Make, I set a filter so that it only runs for records where Publish Date is “Today.” That controls the drip feed of posts.
The fun part — Airtable formulas let you set tomorrow’s date automatically when a post is marked as Scheduled. That way you can “schedule ahead” by just changing the date. The scary part — if you accidentally mark something as Scheduled with today’s date, it’ll be posted in the next Make run. I’ve learned to keep a View in Airtable that only shows posts scheduled for today, so I can sanity check every morning.
If you want finer control, Make’s scheduling options let you run the scenario only on weekdays or specific hours. That’s particularly handy if you have a habit of marking posts late at night and don’t want them going live at 2 AM. I keep those schedules generous to avoid missing the intended run time because the scenario was disabled for edits.
Fixing the silent setting that resets itself
Okay, so here’s the weird one that cost me a day of hair pulling. In Make’s Airtable “Watch Records” module, there’s a hidden setting that specifies “Search By Field.” By default, it’s some internal field like Record ID, but if you change it to “Last Modified Time” and don’t save the module, the edit won’t apply. It looks fine in the UI until you re-open the module, and bam — back to Record ID. That means your scenario just won’t catch updates. I have no idea why it doesn’t throw an error, it just says “No records found” forever.
My prevention hack — right after editing the module, I save the whole scenario, close the browser tab, and reopen it fresh before running a test. If the setting survived the reload, you’re good. This feels ridiculous, but I’ve done it enough times now that it’s an actual step in my workflow checklist 🙂
Keeping logs to avoid future headaches
I know logs sound boring, but when this thing fails silently, you need proof of what changed. I keep a separate Airtable table called “Automation Log” where Make appends a record every time it runs. It logs the post title, date, run status, and any error messages. This is a lifesaver when you’re trying to figure out why nothing published yesterday, because you can immediately see if Make even ran or if Airtable never served the record.
I also add a text field for “Notes” so I can jot down that I disabled the scenario for maintenance or that a bug was found. That way when I stumble into the problem again six months later, I’m not trying to remember why I added a random filter step. This table has bailed me out more than once when a change I made weeks earlier came back to bite me.