Notion Project Database + Project Workspace Template Design for Powerful Project Management
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.
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)?
How does the progress bar work when project outcomes are measurable versus hard to quantify?
What’s the purpose of status categories like on hold, next up, future, and someday maybe?
Why separate internal projects from client projects in different databases?
How does the project workspace template speed up creating and managing new projects?
What role does the “why this project” note play inside each project page?
Review Questions
- When would a project’s progress be calculated with a formula instead of a subjective weekly estimate, and why?
- How do status rules (especially the distinction for “on hold”) affect how projects move through reviews?
- 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
Every internal project is linked to at least one Goal Outcome and one Pillar so execution stays aligned with higher-level priorities.
- 2
Active projects are filtered to exclude completed work and sorted by status, quarter, and priority to keep the most urgent initiatives visible.
- 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
Active projects must have at least one related action item (task); otherwise they become orphaned and can’t move forward.
- 5
Client work is separated into a Client database to prevent cluttering the internal Projects list and to keep active project management manageable.
- 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
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.