Notion content planner: the database, the properties and the views that run a real content calendar

A Notion content planner should be one database, not a page of linked documents. Create a single database where every row is one piece of content, give it properties for status, type, owner, target publish date, channel, target query or topic, funnel stage and a link to the live URL, then build four views on top of it: a board grouped by status for daily work, a calendar by publish date for planning, a table filtered to this week for the weekly meeting, and a table of published items for performance review. One database with several views is what makes the plan hold up, because every view reads from the same rows, so updating a status in one place updates it everywhere and nothing ever has to be copied between a calendar and a tracker.

This page covers building the planner in Notion. For choosing what to publish, see a page on building a content plan from search demand.

The one database rule

The most common mistake is building a calendar page, a separate ideas page and a separate published list. Within a month they disagree with each other and the team stops trusting all three. Create one database called Content, add every idea to it as a row the moment it appears, and let status carry the item through its life from idea to published. Nothing moves between databases, only between statuses.

The properties, and what each one is for

Property	Type	Why it is there
Title	Title	The working headline, rewritten later. Keep it descriptive, not clever
Status	Status or select	Idea, Approved, Writing, In review, Scheduled, Published, Parked. Seven is enough
Owner	Person	One name, never two. Shared ownership is how items stall
Type	Select	Article, landing page, newsletter, video, social post, case study
Channel	Multi select	Where it goes: blog, email, LinkedIn, YouTube
Publish date	Date	Drives the calendar view. Always filled in, even if provisional
Target topic or query	Text or relation	The one thing this piece is meant to be found for
Funnel stage	Select	Awareness, consideration, decision, retention. Shows imbalance at a glance
Brief	Page content	Write the brief in the row itself so it travels with the item
Live URL	URL	Filled on publish. Turns the planner into a content inventory
Pillar	Relation	Links to a Topics database, so you can see coverage per theme
Last reviewed	Date	Drives the refresh cycle for content you already published

Resist adding more. Every extra property is a field somebody has to fill, and a planner that is tedious to update becomes inaccurate, which is the only real failure mode here.

The four views

• Board by status. The daily working view. Group by Status, filter out Published and Parked, and sort by publish date so the most urgent card sits at the top of each column.
• Calendar by publish date. The planning view. Shows gaps and clusters immediately, and dragging a card changes the date, which is the fastest way to rebalance a month.
• This week, as a table. Filter publish date to the next seven days, show owner and status only. This is the view for the weekly meeting, and it should fit on one screen.
• Published inventory. Filter to Published, show title, live URL, publish date, target topic and last reviewed. This is where performance review and content refreshes happen.

Two optional views earn their place on larger teams: a view grouped by owner for workload, and a view filtered to Idea and sorted by date added, which is the backlog you pull from at planning.

The second database worth having

Add a Topics database with one row per theme you want to own, and relate your content rows to it. Each topic row then shows every piece you have published on that theme, which answers the two questions that matter in a planning meeting: where are we thin, and what already exists that we should update instead of writing again. Keep it to a dozen or so topics, because a long list stops being a strategy.

The workflow that keeps it accurate

• Capture immediately. Every idea becomes a row with a status of Idea and an owner of whoever suggested it. Ideas kept anywhere else disappear.
• Brief before writing. The brief lives in the row: the target topic, the reader, the question the piece answers, the three points it must cover, and the next action for the reader. Status moves to Approved only when the brief is written.
• One weekly meeting on the This week view. Fifteen minutes. What ships, what has slipped, what needs a decision.
• Status changes on the board, by owners. Not by a manager at the end of the week.
• On publish, paste the live URL and set last reviewed to today. This single habit is what turns a planner into a usable inventory.
• Monthly, work the Published view. Sort by last reviewed, take the oldest items on your most important topics, and update them. Refreshing an existing page is usually faster and more productive than writing a new one.

Keeping it fast as it grows

Large Notion databases slow down when views load thousands of rows with many relations and formulas. Three habits keep it quick: filter every view rather than relying on scrolling, archive content older than a couple of years into a separate database rather than deleting it, and keep formula properties to the few you genuinely read. If you need templates, use database templates so a new row arrives with the brief structure already in it, which also enforces the standard without anybody policing it.

Should I use a Notion template or build my own?

Build the single database yourself, because it takes under an hour and you will understand every property. Templates are useful to look at for ideas about views and automations, and most arrive with more properties than a team will maintain.

Can Notion replace a dedicated editorial tool?

For planning, briefing, status tracking and inventory, yes, and it has the advantage that the brief and the draft live in the same place as the plan. Teams that need approval workflows with audit trails or direct publishing into a CMS usually keep Notion for planning and connect it to the publishing tool.

How do I handle recurring content like a newsletter?

Use a database template with the standard structure, and create the rows for the whole quarter in advance with provisional dates. Empty scheduled rows prompt the work far better than a reminder does.

How many statuses should the planner have?

Five to seven. Idea, Approved, Writing, In review, Scheduled, Published, with Parked for things you have consciously stopped. More statuses mean more arguments about which one applies.

Should the drafts live in Notion too?

Writing inside the row keeps the brief, the draft and the comments together, which is the main reason to use Notion for this. Teams whose writers prefer another editor should keep a link property to the draft document and leave the brief in the row.

A planner column for the question each post answers

Your published view tracks status, owner and date. Add one property: the buyer question the post answers, written as someone would say it to an assistant.

Then, a few weeks after publishing, ask the assistants that question and record whether your page is cited. The planner turns into a record of what worked. AI Knows Us will ask the question across several assistants for you, and you paste the result into that column.