Notion Masterclass: Build a Second Brain from Scratch

TL;DR

Build PARA in Notion using connected databases: Tasks, Notes, Projects, and a merged Areas/Resources database, plus linked filtered views for Archive.

Briefing Cornell Notes

Briefing

A complete PARA “second brain” system can be built from scratch in Notion by treating Projects, Areas, Resources, and Archive as connected databases—then driving everything through templates, linked views, and a couple of inboxes for capture. The payoff is a single place where tasks and notes can live together under the same project or life area, instead of splitting work across separate tools.

The system starts with a dashboard that provides a bird’s-eye view of PARA plus two capture inboxes: a task inbox for quick actionable items and a note inbox for ideas and clipped content. From there, the core PARA structure is implemented using four concepts: Projects (ongoing goals made of tasks), Areas (life buckets maintained over time), Resources (topics and reference material), and Archive (completed or irrelevant items kept for later retrieval). A key design choice is that Notion’s database flexibility allows notes to belong to multiple “parents” in practice—notes can relate to projects, areas, or resources—so the system supports richer context than folder-based PARA implementations.

To make PARA work cleanly in Notion, the build uses five main databases: Tasks, Notes, Projects, and a combined Areas/Resources database, plus an Archive page that links out to filtered views. Tasks get a status property (with defaults for “not started,” “in progress,” and “done”) and a due date. Notes get a URL property and a formula field called base URL that extracts the domain from any link, enabling grouping of web clips by source site. Projects also use a status property, while the combined Areas/Resources database uses a “type” status to distinguish Areas (orange) from Resources (purple). An “archive” checkbox property is added to the non-task databases to support moving items out of active views without deleting them.

Relations tie the system together: tasks relate to exactly one project; notes relate to projects and also to the combined Areas/Resources database; projects relate to areas; and resources relate back to a single “root area.” A rollup on Notes pulls the root area through the resource relationship, enabling area dashboards to show not only notes directly linked to the area, but also notes nested inside resources contained by that area.

Templates then enforce consistency. A project template creates a “quick links” section, a project overview callout, and two-column layouts with linked task and note views filtered by a self-referential condition (e.g., “project contains project template”), so new projects automatically populate the right views. Area/Resource templates use different layouts: projects appear as a board grouped by status, resources appear as a gallery with cover cards, and area notes combine direct notes with resource-contained notes via the rollup. Finally, the main dashboard assembles linked views: inboxes filter for items where project/area/resource relations are empty, while “next seven days” and “completed” are separate task views. An Archive page completes the loop by linking filtered lists for completed tasks and archived notes/projects/areas/resources.

The result is a PARA system that’s both capture-friendly and context-rich: tasks and notes can be processed from inboxes into projects and life areas, while archived material stays searchable instead of disappearing. It’s a practical blueprint for building a true second brain inside Notion using database relations, rollups, and template-driven dashboards.

Cornell Notes

PARA in Notion is built by connecting five database layers—Tasks, Notes, Projects, Areas/Resources (merged), and Archive—so tasks and notes can be organized under the same life context. Tasks link to one Project; Notes link to Projects and to the combined Areas/Resources database, with a rollup that lets an Area dashboard display notes inside Resources contained by that Area. Templates make the system scalable: a Project template creates filtered linked views for tasks and notes using self-referential filters, while Area/Resource templates use board/gallery/list layouts with archive-aware filters. Two inbox views handle capture: tasks move out of the inbox once assigned to a project, and notes move out once assigned to a project or area/resource. The Archive page then links filtered views based on the archive checkbox and completion status.

Why merge Areas and Resources into a single database in this PARA setup?

Merging Areas and Resources into one database keeps the interface cleaner and reduces duplicated properties and views. Instead of maintaining separate tables (and separate “area” vs “resource” filters) the system uses one relation target and differentiates items with a “type” status property (Areas vs Resources). That matters when building linked views on smaller screens and when creating filters like “root area contains area template,” because everything flows through the same underlying structure.

How does the system make an Area dashboard show notes that are stored inside Resources?

Notes relate to the Areas/Resources database, and Resources relate back to a single “root area.” A rollup property on Notes retrieves the root area through the resource relation. Then the Area notes view can filter using the rollup (e.g., “root area roll-up value contains area template”), which effectively includes notes nested in resources contained by that area—not just notes directly linked to the area.

What role do templates play in keeping the system consistent?

Templates automate the wiring of linked views and filters. The Project template sets up linked task and note views filtered by a self-referential condition (project contains project template), so each new project automatically shows only its own tasks and notes. Area and Resource templates similarly preconfigure layouts (board for projects, gallery for resources, list for notes) and apply default templates for new rows, ensuring every area/resource instance behaves the same way without manual re-filtering.

How do the inbox views work, and what triggers items to leave them?

The task inbox shows tasks where the project relation is empty and the task is not complete. Once a task is assigned to a project, it no longer matches the “project is empty” filter and disappears from the inbox. The note inbox uses “area/resource is empty” and “project is empty” plus “archive unchecked,” so notes leave the inbox once they’re assigned to a project or to an area/resource. This makes inboxes a capture-and-process queue rather than a permanent holding area.

Why include a URL property and a base URL formula for Notes?

The system distinguishes web clips from personal notes by whether a note has a URL. The base URL formula extracts the domain from any link, enabling grouping of web clips by source site (e.g., multiple clips from the same site appear together). Views then filter notes by URL empty vs not empty to create separate tabs for “Notes” and “Web Clips,” and group web clips by base URL for faster scanning.

What is the purpose of the archive checkbox and how does it propagate through the system?

The archive checkbox (added to Projects, Areas/Resources, and Notes) acts as a soft-delete mechanism. Views filter for “archive is unchecked” to keep active dashboards clean, while the Archive page links lists filtered for “archive is checked” (and tasks filtered by done status). This ensures completed or irrelevant items move out of daily views but remain retrievable later without losing data.

Review Questions

If an Area dashboard needs to show notes inside Resources contained by that Area, which Notion feature in this setup makes that possible (relation, rollup, or template filter)?
What combination of filters keeps the task inbox focused on actionable items that still need processing?
How does the base URL formula change how web clips are organized compared with storing only full URLs?

Key Points

1
Build PARA in Notion using connected databases: Tasks, Notes, Projects, and a merged Areas/Resources database, plus linked filtered views for Archive.
2
Use relations to define structure: tasks → one project; notes → projects and areas/resources; projects → areas; resources → one root area.
3
Add a rollup on Notes to pull the root area through the resource relationship, enabling area dashboards to include resource-contained notes.
4
Use templates with self-referential filters so each project/area/resource instance automatically generates the correct linked views and stays consistent.
5
Create inbox views for capture: tasks leave the inbox when assigned to a project; notes leave when assigned to a project or area/resource.
6
Separate web clips from personal notes using a URL property and a base URL formula, then filter/group views accordingly.
7
Use an archive checkbox and filtered linked views to keep active dashboards uncluttered while preserving everything for later retrieval.

Highlights

The system’s “single dashboard” advantage comes from letting notes and tasks share the same project/area context through relations and rollups.

A rollup on Notes is the mechanism that makes Area dashboards include notes stored inside Resources contained by that Area.

Self-referential filters inside templates keep linked views automatically synced to the specific project/area/resource instance.

Two inboxes (tasks and notes) function as a capture queue, then processing happens by assigning relations so items naturally fall out of inbox views.

Merging Areas and Resources into one database simplifies filtering and makes the UI more scalable in Notion.