Notion Office Hours: Build With Me 🏗

TL;DR

Use databases for anything that needs properties, filtering, and relational connections; use pages as flexible containers for content and embedded views.

Briefing Cornell Notes

Briefing

Notion’s real power—especially for “second brain” and client-workflows—comes from using databases (with relations, templates, and embedded filtered views) instead of treating everything as standalone pages. The session’s core message is that pages are flexible containers, but databases are what make information connectable: projects can link to tasks, tasks can link to calendar items, and the same underlying data can be surfaced in multiple views without duplicating it.

A live walkthrough centered on a practical structure for work management. A master tasks database holds day-to-day tasks across personal and client work. A calendar acts as an editorial/content scheduler with multiple filtered views (by project type, by client, by personal vs. client work). “Areas” (business domains like Notion Office Hours, a Notion course, and other project categories) were moved into a database so they can be related to projects and tasks. The key operational trick: entries can be dragged between database and page forms if the workflow changes, while relations preserve the ability to see connected items.

Embedded databases were presented as the mechanism for “no task slips through the cracks.” Instead of relying on a single task list, tasks are surfaced in several places—dashboard, weekly agenda, and journal—through embedded views that filter to the relevant subset. The same idea scales to projects and sub-projects: one approach is to keep everything as projects and use tagging/relations to represent parent-child structure, then embed a filtered sub-project view inside the parent project page.

The session also tackled one of the most confusing Notion concepts: why not make everything a page with an embedded database? The answer was that databases enable properties, multiple view types (table, gallery, reading list), and—most importantly—filtering and relational connections. Pages can contain embedded databases, but pages themselves don’t provide the same property-based filtering and cross-item linking. A database can also be embedded across many pages, letting the same data appear in different contexts (e.g., a Christmas list database viewed as a budget dashboard vs. a shopping-time checklist).

Client sharing and permissions emerged as the hardest edge case. Notion’s permission model doesn’t support fine-grained “hide some properties but keep the rest clickable” for linked/embedded data in the way many users want. Workarounds discussed included creating separate “safe” client-facing databases (or duplicated/simplified templates) that contain only the fields clients should see, then relating or copying only the necessary information. Another strategy: share a public page that reveals only a specific embedded view, while keeping the master database private so it appears blank to clients even when embedded.

Finally, a hands-on Q&A explored database “inception” and rollup limitations. For meal planning and shopping lists, the goal was to aggregate ingredients across a week. The discussion highlighted that rollups can’t always roll up rollups, so the workaround often involves restructuring relations (e.g., connecting ingredients to days/meals in a way that allows direct filtering) or using filtered views rather than multi-layer rollups. Overall, the session emphasized iterative refinement: start with templates, build small, then add relations and embedded views as the system becomes clearer.

Cornell Notes

The session argues that Notion becomes dramatically more useful when information lives in databases that can be related, templated, and embedded as filtered views—rather than being stored as isolated pages. A common workflow uses a master tasks database, a calendar for scheduling, and an “areas” database linked to projects and tasks so connected work can be surfaced everywhere (dashboard, weekly agenda, journal). Pages are still valuable as containers, but databases provide property-based filtering and multiple view types that make relationships visible. Client sharing is limited by Notion’s permissions model, so teams often create simplified client-facing databases or public pages that expose only the needed embedded views. Rollups and multi-step aggregation can hit limitations, so restructuring relations or relying on filtered views is often the practical fix.

Why does the session treat databases as more than “bancier pages” in Notion?

Databases provide structured properties and, crucially, relational connections. In the walkthrough, tasks are stored in a tasks database and then related to projects (and projects to areas). That relation lets a project page show every associated task, and it also enables embedded filtered views—like showing “tasks for today” on a dashboard and weekly agenda without duplicating task records. Pages can host embedded databases, but pages themselves don’t offer the same property-based filtering and relational linking.

How do embedded databases help prevent tasks from being missed?

Instead of keeping tasks in one place, the same tasks database is surfaced in multiple contexts via embedded views. The session’s example: tasks appear on a dashboard, in a weekly agenda, and inside journal entries. Each embedded view is filtered to the relevant subset, so creating a new task automatically shows up wherever the filtered views point—reducing the chance that something “falls through the cracks.”

What’s the practical approach to representing sub-projects and parent projects?

A recommended method is to keep everything as projects and use relations/tags to represent hierarchy. Then a parent project page can embed a filtered view that shows only sub-projects tied to that parent. The session also mentioned an alternative: create a separate sub-project database (if some sub-projects shouldn’t appear in the master list), but the core idea is using relations plus filtered embeds to group work.

Why can’t a client-facing page always hide sensitive fields while still letting clients interact with the rest?

Notion’s sharing permissions don’t provide the fine-grained “partial view” control many users expect for embedded/linked data. The session described a workaround: build a separate client-safe database (or duplicated template) that contains only the fields clients should see, then relate or copy only the necessary information. Another tactic is embedding a private master database in a way that renders blank for clients, while exposing only the client-specific tasks or views.

What rollup limitation came up in the meal-planning shopping list example?

The goal was to aggregate ingredients across a week by rolling up from day-level data to a weekly list. The issue: a rollup of a rollup wasn’t available as an option, so the multi-layer aggregation approach failed. The practical direction was to restructure relations so ingredients connect in a way that supports direct rollups or to use filtered views (e.g., filter ingredients by days/meals assigned to a week) rather than relying on rollups across rollups.

How does templating change the day-to-day effort of maintaining a Notion system?

Templates reduce repetitive setup. The session emphasized database templates and inline templates for tasks and proposals—so when a new task is created (e.g., a “Girl Guides” volunteer task), predefined properties like icons/tags and default fields are applied automatically. That shifts time from “building the structure every time” to “using the structure,” making ongoing maintenance feel fast once the system is set.

Review Questions

In a system where projects relate to tasks, what embedded views would you create so tasks appear in both a dashboard and a weekly agenda without duplicating task records?
What are two different reasons to prefer a database over a page in Notion, based on the session’s examples?
When client permissions need to hide sensitive properties, what workaround patterns were discussed, and why are they necessary?

Key Points

1
Use databases for anything that needs properties, filtering, and relational connections; use pages as flexible containers for content and embedded views.
2
Connect projects to tasks (and tasks to calendar/journaling contexts) using relations so the same records can be surfaced across multiple places.
3
Represent sub-projects via tagging/relations and embed filtered views inside parent project pages to keep hierarchy manageable.
4
Embedded databases are the mechanism for “single source of truth” plus multiple perspectives—dashboard, agenda, and journal can all show different filtered slices of the same data.
5
Notion’s permissions don’t reliably support fine-grained hiding of linked/embedded fields for clients; create client-safe simplified databases or public pages that expose only the needed views.
6
Rollups can be limited (including rollup-of-rollup constraints), so restructure relations or rely on filtered views when multi-step aggregation doesn’t work.
7
Templates (database and inline) are the fastest way to reduce setup time and standardize repeated workflows like proposals and recurring tasks.

Highlights

The session’s “no excuse to miss tasks” workflow comes from embedding filtered views of a single tasks database into multiple areas (dashboard, weekly agenda, journal).

Moving “areas” into a database unlocks relations to projects and tasks—and the setup can be adjusted later by dragging entries between page and database forms.

Client sharing often requires building separate simplified/safe databases because Notion’s permission model doesn’t provide the expected partial-field visibility for linked/embedded data.

Rollup-of-rollup aggregation can fail in practice, pushing users toward relation restructuring or filtered views for weekly shopping list totals.

Topics

Mentioned

Marie Poulin