Get AI summaries of any video or article — Sign up free
Creating a company wiki (Block × Block) thumbnail

Creating a company wiki (Block × Block)

Notion·
5 min read

Based on Notion's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Use a “Company Home” page as the source of truth, organizing wiki content into sections and columns so users get context when they navigate.

Briefing

A Notion company wiki can stay organized and up to date by combining two approaches: a traditional page-based layout for quick navigation and a database-backed structure for scalable governance. The key difference is that database properties—like Owner, Section, Last edited time, and Last updated—turn wiki maintenance into something you can sort, filter, and monitor, rather than relying on manual scanning.

The walkthrough starts with a “Company Home” homepage that acts as the source of truth. It’s built from top-level sections (for example, “What’s New,” “Mission and Values,” “Policies and Benefits,” and an “Employee Directory” area) arranged in columns. Navigation matters: using the left sidebar helps people reach top-level pages, but it can hide context about where specific topics live. The solution is to guide users through the wiki’s internal page structure so they land in the right section and see related content together.

To make the wiki actionable, the page layout uses small but practical features. Each section can include contextual text (such as gray notes) and reminders for owners. Page ownership is handled by mentioning a person and attaching a date, then converting it into a Reminder that can trigger a notification ahead of the due date. A callout block at the top can also highlight “must read” documents, linking directly to other pages so new or returning employees immediately know what to prioritize.

From there, the guide shows how to build the same structure from scratch using Notion’s block tools: headers, dividers, sub-pages, and inline databases. It demonstrates how to create a homepage with a column layout by dragging section blocks using the block handle and aligning them to the blue drop line. It also covers practical formatting controls like full-width pages and adjustable column widths.

The scaling upgrade comes next: duplicating the wiki content into a database. Instead of separate column sections on a single page, each wiki page becomes a database row with properties such as Section (single-select), Owner (person), Description, and a “Needs updating on” date. Crucially, Last edited time is surfaced as an automatic property, making it easy to see when content changed and who last touched it. Database views then replace manual organization: filters can show only “Team” content or only “Policies,” and sorting by Last edited time reveals what’s most recently updated.

The database also supports a “highlight” pattern to mimic callouts. A Highlight property can be tied to a star label so key pages appear as must-reads across views. Finally, the guide explains how to create the database structure (table with Page and Section fields, plus owner and date properties), populate it with sub-pages, and even migrate existing wiki content by dragging pages into the database so they become rows or sub-pages.

By the end, the wiki isn’t just a static library. It becomes a system: page-based for clarity, database-backed for governance—especially when the number of documents grows and keeping them current becomes a real operational need.

Cornell Notes

The strongest takeaway is that a Notion company wiki works best when it blends a clear homepage layout with a database-backed structure for maintenance. A page-based “Company Home” organizes content into sections, columns, and sub-pages, and it can add reminders, owners, and “must read” callouts. When the wiki grows, moving content into a database turns key metadata into properties like Section, Owner, and Needs updating on, plus automatic Last edited time. Those properties enable sorting and filtering through dedicated views (e.g., “Team Content,” “Policies Content,” “Recently updated”), making it easier to track what changed and who is responsible. This approach reduces manual checking and helps keep enterprise-scale documentation current.

Why does a database-backed wiki become easier to manage than a page-only wiki as content grows?

A page-only wiki can show ownership and reminders, but those details aren’t inherently structured for sorting and filtering. In the database approach, each wiki page becomes a database row with properties such as Owner (Person), Section (Single-select), and Needs updating on (Date). Notion also provides automatic properties like Last edited time and Last editor. Because those values are properties, the wiki can surface them directly in views, sort by Last edited time, and filter by Section or Owner—so teams can quickly find what’s outdated or recently changed without manually opening pages.

How do reminders and ownership work in the page-based wiki layout?

Ownership is added by mentioning a colleague with the @ symbol and then attaching a date. Converting that into a Reminder schedules a notification (for example, one week before the due date). The reminder state becomes visible on the page (including a clock indicator), and it can be adjusted to trigger on the day of the event or one day before. This same pattern is shown for multiple pages, such as a “Company Home” owner/update date and a “What’s New” page owner/update date.

What’s the practical role of “must read” callouts, and how is that replicated in a database?

On the homepage, a callout block highlights must-read documents and links to other pages so users know what to prioritize immediately. In the database version, the same idea is implemented through a Highlight property. Pages that should be emphasized get a star label (via the emoji picker/label workflow), and views can then surface those highlighted items—effectively turning callouts into a reusable, property-driven system.

How does the guide build a multi-column wiki layout on a page?

It uses block-level movement: sections are selected via their block handles and dragged until a blue drop line indicates where the content will land. Dropping a section to the right pushes other content down, creating a column structure. Column width can be adjusted by dragging the gray vertical line, and the page can be toggled to Full width to fit more columns in a single row.

What does a database view add that a static homepage can’t?

Views provide structured navigation and operational oversight. For example, a “Team Content” view filters rows where Section equals Team, while a “Policies Content” view filters Section equals Policies. Another view, “Recently updated,” sorts by Last edited time so the newest changes rise to the top. This turns the wiki into a living dashboard for documentation health.

How can existing wiki content be migrated into the database format without rebuilding everything?

Instead of recreating content, pages can be dragged into the database. Dropping a page into a database row creates a row entry; dropping it within an existing row can make it a sub-page. After migration, properties like Owner and Section can be assigned or updated in bulk using Edit Property, including updating dates such as Needs updating on for multiple rows at once.

Review Questions

  1. When would a team choose a page-based wiki layout over a database-backed wiki, and what breaks first as the wiki grows?
  2. How do Last edited time and Last editor change the way a wiki can be monitored compared with reminders and mentions alone?
  3. Describe two different ways views can help users find the right wiki content (e.g., filtering vs sorting).

Key Points

  1. 1

    Use a “Company Home” page as the source of truth, organizing wiki content into sections and columns so users get context when they navigate.

  2. 2

    Add operational metadata on pages—owners and reminders—so documentation has clear responsibility and update cycles.

  3. 3

    Use callout blocks to surface must-read documents and link directly to the relevant pages.

  4. 4

    When the wiki becomes large, move content into a database so metadata becomes properties like Section, Owner, Needs updating on, and automatic Last edited time.

  5. 5

    Create database views that filter and sort by properties (e.g., Team vs Policies, Recently updated) to make maintenance and discovery easier.

  6. 6

    Migrate existing wiki content by dragging pages into the database so they become rows or sub-pages, then update properties in bulk when needed.

  7. 7

    Use a Highlight property (e.g., star labels) to replicate callout-style emphasis in a scalable, view-driven way.

Highlights

A database-backed wiki turns maintenance into a system by making Last edited time and Last editor visible and sortable.
Reminders on page-based wiki sections can be scheduled by mentioning an owner and attaching a date, then converting it into a Reminder.
“Must read” guidance can be implemented twice: as callout blocks on pages and as a Highlight property (star label) inside a database.
Column-based homepage layouts rely on block handles and blue drop lines to place sections precisely.
Database views act like operational dashboards—filtering by Section and sorting by Last edited time reveals what needs attention.

Topics

Mentioned

Get summaries like this for any content

Videos, articles, research papers — all summarized by AI and searchable in one place.

Start building your library