Airtable is close to ideal for a content calendar. Grid and calendar views over the same data, attachments alongside the text, collaborators, and views per campaign.
Getting from there to published posts is a short workflow, with two details that decide whether it’s reliable.
Fields worth having
| Field | Type | Purpose |
|---|---|---|
| Content | Long text | The post |
| Status | Single select | Draft, Ready, Published |
| Channels | Multiple select | Target platforms |
| Publish at | Date | Scheduled time |
| Media | Attachment | Images or video |
| Post URL | URL | Written back after publishing |
Airtable’s attachment field is the real advantage over a spreadsheet here: the media lives with the row rather than as a URL you have to host somewhere.
The workflow
1. Schedule Trigger, every 15 or 30 minutes.
2. Airtable node, search records with a filter of Status = "Ready". This is the gate, and it’s the reason the workflow doesn’t publish half-written rows.
3. Filter on the publish date if the row should control timing.
4. Build the post from the fields, mapping the multi-select channels to the channel list.
5. BulkPublish node, Post → Create.
6. Airtable node, update the record. Set Status to Published and write the post URL back.
Step 6 is not optional
Without the write-back, the next run finds the same rows still marked Ready and publishes them again. Then the run after that. A workflow polling every 15 minutes will republish the same post 96 times a day.
This is the single most common way these workflows go wrong, and the symptom is embarrassing in public.
If you want belt and braces, also filter out records that already have a Post URL. Two independent checks, so one failing doesn’t produce duplicates.
Attachments
Airtable attachments come with URLs, which is what you pass through. Two things to know.
Attachment URLs can be time-limited. Don’t build a workflow that stores one now and uses it days later without re-fetching.
Check the file against the platform’s rules. Airtable will happily hold a 50 MB image that Instagram won’t take. Media rules are validated when the post is created, so you’ll get a clear error rather than a silent failure, but the workflow should log it somewhere you’ll see.
Scheduling versus publishing now
Prefer mapping the Publish at field to a scheduled time rather than publishing whenever the workflow happens to run.
Two reasons: rows get marked Ready when someone is at their desk, which isn’t when your audience is reading, and a scheduled post can still be cancelled if the row turns out to be wrong.
Draft first
For the first week, create drafts. You’ll see how the field mapping actually lands, particularly around channels and attachments, before anything is public.
Plan limits
- Channels: Free: 3 (1 per platform). Pro: 30 (2 per platform). Business: 75 (5 per platform).
- Posts: Free: 3/day. Pro: 30/day. Business: unlimited.
- API requests/day: Free: 30. Pro: 5,000. Business: 50,000.
A workflow polling every 15 minutes uses 96 requests a day before publishing anything, so the free tier is for testing rather than running this.
BulkPublish publishes to 15 platforms.
The short version
Filter on a Status field so drafts stay unpublished, and write back to Airtable after publishing so rows aren’t picked up again, which is how these workflows produce duplicate posts. Map Publish at to a scheduled time rather than posting on trigger, and check attachments against the platform’s media rules.