Get AI summaries of any video or article — Sign up free
Notion Project Database + Project Workspace Template Design for Powerful Project Management thumbnail

Notion Project Database + Project Workspace Template Design for Powerful Project Management

August Bradley·
6 min read

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

TL;DR

Every internal project is linked to at least one Goal Outcome and one Pillar so execution stays aligned with higher-level priorities.

Briefing

A Notion “Projects” database can become the hub of a full project-management system when every project is tied to higher-level priorities (goal outcomes), supporting strategy (pillars), and executable work (action items). The core move is treating each project as an internal workspace that stays connected to tasks and to quarterly/weekly review cycles—so teams don’t just track work, they continuously verify they’re building the right things.

The setup starts in the Alignment Zone dashboard, where “Active Projects” is the primary Projects view. Completed projects are filtered out, leaving only in-progress work plus carefully staged “next up,” “future,” and “someday maybe” items. Status isn’t just cosmetic: “on hold” requires the project to have started before it can be paused, while “next up” and “future” represent different distances from activation. Projects are also sorted by quarter (via a linked Quarter database) and by a priority rating to keep the most important initiatives visible at the top.

Each active project gets a progress bar, but the system distinguishes between measurable and messy projects. When outcomes are countable—like producing 15 podcast episodes—the progress is calculated from completed items. When outcomes are variable and task counts can’t be known upfront, progress becomes a subjective weekly-review estimate. That choice is deliberate: it’s faster and more realistic for complex projects, and the same progress indicator appears across the action dashboards for quick status scanning.

The real power comes from relationships. In the projects table, every project is assigned at least one goal outcome and at least one pillar, ensuring projects exist to serve top-level priorities rather than drifting into busywork. Projects also require at least one action item (task). Without tasks, a project becomes an “orphan” that can’t move forward—so the system uses that constraint to keep execution honest.

The transcript also draws a boundary between internal and client work. Internal company/life projects live in the Projects database, while client projects are handled separately in a Client database. Tasks are shared across personal projects and client work, but client projects don’t clutter the internal “active projects” list, keeping the number of active initiatives manageable.

Inside each project page, a template turns the database entry into a workspace. The page foregrounds a “why” statement—short, specific, and hard to evade—so the project’s purpose stays visible during execution. Beneath it, three embedded, filtered lists drive day-to-day work: pillars relevant to the project, goal outcomes relevant to the project, and action items filtered to the current project and excluding completed/private tasks. Tasks can be added as structured items (with status, due dates for active work, priority, and ownership) or brainstormed via a scratchpad that can be dragged into the task database.

Creating new projects is designed to be fast: start from a template page, then apply filters in the embedded databases (pillars, goal outcomes, and action items) by selecting the current project. Once filtered, new tasks created from that view automatically inherit the project relation, and the workspace becomes immediately usable. The result is a connected system where project pages aggregate notes and research for the team, tasks provide execution, and cycle reviews can later realign goals, pillars, and workstreams to keep everything on track.

Cornell Notes

The Projects database is built as a connected hub: every internal project links to at least one Goal Outcome and one Pillar, and every active project must have at least one Action Item (task) so nothing becomes an orphan. Active projects are filtered to exclude completed work, sorted by status, quarter, and priority, and tracked with a progress bar that’s either formula-based (when outcomes are countable) or a subjective weekly estimate (when projects are variable). Each project entry uses a template that embeds filtered views of pillars, goal outcomes, and tasks, plus a prominent “why this project” note to keep purpose visible. New projects are created quickly by applying the template and selecting the current project in each embedded database filter, so task creation automatically inherits the correct project relation.

Why does the system require every active project to have at least one action item (task)?

It prevents “orphaned” projects—initiatives that exist in the Projects database but have no executable work attached. The workflow treats projects as forward-moving containers: without tasks, there’s no mechanism to progress, so the system enforces that active projects must have at least one related task. In practice, the project workspace embeds an action-items list filtered to the current project and excludes done/private items, so the page always reflects what’s actually being worked on.

How does the progress bar work when project outcomes are measurable versus hard to quantify?

When the outcome is countable, progress is formula-based. The example given is a project to produce 15 podcast episodes: completing 4 yields 4/15, or about 27%. For most projects, task totals and task weights vary and can’t be known upfront, so the system uses a subjective progress assessment during weekly reviews. That “ballpark” estimate is considered the most accurate and fastest option for variable projects, and the progress bar appears in the project-related dashboards for quick scanning.

What’s the purpose of status categories like on hold, next up, future, and someday maybe?

Status organizes projects by readiness and management intensity. “In progress” sits at the top because those projects are actively managed. “On hold” is stricter: it only applies after a project has started and then been paused. “Next up,” “future,” and “someday maybe” represent increasing distance from activation, and the system intentionally keeps them visible so they can be reconsidered during weekly/monthly/quarterly reviews rather than forgotten.

Why separate internal projects from client projects in different databases?

The transcript emphasizes keeping the internal “active projects” list clean and manageable. Client projects are stored in a dedicated Client database, and each client entry functions as a workspace for that client with sub-workspaces for collaboration. Tasks are shared across personal projects and client work, but client projects are excluded from the internal Projects view to avoid an unruly list and to maintain clearer prioritization for internal initiatives.

How does the project workspace template speed up creating and managing new projects?

A template page embeds three filtered database views: pillars (filtered to the project), goal outcomes (filtered to the project), and action items (filtered to the project and excluding done/private tasks). To activate the template for a new project, the user applies the correct filter selections in each embedded database—pillars, goal outcomes, and action items—typically by choosing the current project (often the top entry in the filter selector). After that, creating a new task from the filtered action-items view automatically attaches the task to the current project relation.

What role does the “why this project” note play inside each project page?

It’s a short, front-and-center statement written in the project template that forces clarity about purpose. The transcript frames it as a deliberate check against vague intentions: writing it down prevents “wiggle room” and makes the reason for the project visible during execution. In the example, the “why” explains that outsourcing video editing is needed to regain time for new initiatives.

Review Questions

  1. When would a project’s progress be calculated with a formula instead of a subjective weekly estimate, and why?
  2. How do status rules (especially the distinction for “on hold”) affect how projects move through reviews?
  3. What relationships must exist for an active project to be considered properly set up (goals, pillars, and tasks), and what problem does each relationship prevent?

Key Points

  1. 1

    Every internal project is linked to at least one Goal Outcome and one Pillar so execution stays aligned with higher-level priorities.

  2. 2

    Active projects are filtered to exclude completed work and sorted by status, quarter, and priority to keep the most urgent initiatives visible.

  3. 3

    Progress tracking uses formula-based completion when outcomes are countable, and subjective weekly estimates when outcomes are variable and task totals can’t be known upfront.

  4. 4

    Active projects must have at least one related action item (task); otherwise they become orphaned and can’t move forward.

  5. 5

    Client work is separated into a Client database to prevent cluttering the internal Projects list and to keep active project management manageable.

  6. 6

    Each project page uses a template that embeds filtered views of pillars, goal outcomes, and tasks, plus a prominent “why this project” note to maintain purpose.

  7. 7

    New projects are created quickly by applying the template and selecting the current project in each embedded database filter, so task creation inherits the correct project relation automatically.

Highlights

The system treats projects as forward motion: an active project without at least one task is an orphan that needs fixing.
Progress tracking switches methods—formula when outcomes are countable, subjective weekly estimates when projects are too variable for clean math.
Status isn’t just labeling; “on hold” requires a project to have started, and “next up/future/someday maybe” keep future work visible for review.
A project workspace template embeds filtered pillars, goal outcomes, and action items so the page becomes an execution dashboard rather than a static record.
Separating client projects from internal projects keeps prioritization clean and prevents an unruly active list.

Topics

  • Notion Projects Database
  • Project Workspace Template
  • Goal Outcomes Alignment
  • Pillars Filtering
  • Task Relationships

Mentioned