Notion is a good place to plan content: a database view per campaign, properties for whatever you need to track, and comments for review. The problem is the gap between “the row says Ready” and the post actually going out.
Here’s how to close it, and the one thing that makes the difference between this working and it publishing your half-written drafts.
Set the database up first
The workflow is only as reliable as the database behind it. Properties worth having:
| Property | Type | Purpose |
|---|---|---|
| Content | Text | The post itself |
| Status | Select | Draft, Ready, Published |
| Channels | Multi-select | Which platforms |
| Publish at | Date | When it goes out |
| Media | Files or URL | Anything attached |
Status is the important one. Without it, every keystroke in a Notion page is potentially a trigger, and you’ll publish things mid-sentence.
The workflow
1. Schedule Trigger. Run every 15 or 30 minutes. Notion triggers on change are available, but polling on a schedule and filtering by status is more predictable for this, because a database row gets edited many times before it’s finished.
2. Notion node, get database pages. Filter to Status = Ready. This is the gate. Nothing that isn’t explicitly marked ready gets near a platform.
3. Filter on the publish date if you want the row to control timing rather than posting everything ready right now.
4. Build the post. Map Notion properties to content and channels. If your Channels property is a multi-select, this is where you turn those values into the channel list.
5. BulkPublish node, Post → Create. Content, channels, and optionally a scheduled time.
6. Notion node, update the page. Set Status to Published and write back the post’s id or URL.
That last step is the one people skip, and it’s what stops the workflow republishing the same row on the next run. Without it, every run picks up every Ready row again.
The trap: Notion’s rich text
Notion content is structured, not plain. Headings, bold, bullets, toggles and links all carry formatting that social platforms don’t accept.
If you pass a Notion block straight through, you get either markdown syntax rendered literally in the post, or an empty post if the extraction picked the wrong field.
Extract plain text deliberately, and check what a real row produces before trusting it. This is the most common reason these workflows produce odd-looking posts.
Do you need n8n for this?
Worth asking. If you’re planning in Notion and want posts to go out, there’s a direct Notion integration that doesn’t require running a workflow at all.
Build the n8n version when you need something in between: filtering on properties, transforming the text, routing different content types to different accounts, or pulling in a second source.
Run it into drafts first
For the first week, have the workflow create drafts rather than publishing. You’ll see exactly what the Notion-to-post mapping produces, especially the rich-text handling, before an audience does.
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.
The free tier’s 30 requests a day is for evaluating an automation. A workflow polling every 15 minutes uses 96 requests a day before it publishes anything.
BulkPublish publishes to 15 platforms: Facebook, Instagram, TikTok, YouTube, X, Threads, Bluesky, Pinterest, Google Business Profile, LinkedIn, Mastodon, Discord, Telegram, Tumblr and Snapchat.
The short version
Add a Status property and filter on it, or you’ll publish drafts. Write back to Notion after publishing, or you’ll republish every run. Extract plain text deliberately, because Notion’s rich text does not survive the trip. And check whether the direct Notion integration does what you need before building a workflow to maintain.