Get AI summaries of any video or article — Sign up free
The Notion task manager you'll actually use (full build) thumbnail

The Notion task manager you'll actually use (full build)

6 min read

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

TL;DR

Build the system around three databases (Tasks, Projects, Task Journal) and connect them with a one-to-many Relation from Projects to Tasks.

Briefing

A complete, usable task manager in Notion can be built from a blank page by treating Notion databases like the underlying “app engine,” then layering purpose-built views on top—an inbox, daily and weekly planning, scheduled lists, and project dashboards—so everything you need lives behind one homepage.

The build starts by creating an “ultimate tasks” homepage set up like an app canvas (full width, minimal distractions). From there, three inline databases power the system: a tasks database, a projects database, and a task Journal database for daily planning. The tasks database is converted into a Notion “task database” schema by adding core properties such as Status and Due date, then expanded with practical fields: Priority (implemented as a status-style property with defaults), Smart list for “someday” tasks, Description, Created/Edited timestamps, and—critically—a Relation to Projects. That relation is configured as one project to many tasks, with a two-way link so projects can show their tasks.

To make task pages feel fast and readable, the layout for each task page is customized: frequently used properties (Status, Due date, Project) are pinned under the title, while helper properties move into a side panel. A key helper property is Meta labels, a formula that outputs icons for overdue tasks and recurring tasks. This formula is designed to work across all list views so the same visual cues appear everywhere without rework.

Next comes the daily workflow layer: views duplicated from a source “active tasks” database. The system creates an Inbox view that automatically clears when tasks are completed, assigned to a project, or moved out of Smart list “someday.” It then duplicates into Today (tasks due today), a Week calendar view, a Scheduled view that groups tasks by due-date ranges, and a No due view for tasks waiting on dates. Additional views provide “By project” grouping and consolidated lists for All unfinished tasks and Done tasks.

Projects receive the same treatment. The projects database adds a richer Status set (planned, on hold, doing, ongoing, done), an Archived checkbox, Created/Edited timestamps, and a Progress formula that renders a progress bar based on completed tasks. A project page template is created so every new project automatically spawns embedded task views filtered to tasks that belong to that project—using a self-referential filter so the template always points to the correct project page. This turns each project into a mini dashboard with list, board, and calendar views of its tasks.

Advanced features are then layered in. Recurring tasks are implemented with recur interval and recur unit properties plus a Next due formula (using dateAdd). On paid plans, an automation can update Due date when tasks are checked off; a dedicated recurring-tasks view makes manual processing possible when automations aren’t available. Subtasks are enabled via Notion’s built-in subtasks feature, but the build warns about a common pitfall: subtasks don’t automatically inherit the parent’s project relation, so filtered project views may “lose” subtasks unless views are configured carefully (e.g., showing parents only in inbox-style views and using flattened lists for date-based views).

Finally, the system adds usability polish: a mobile-friendly button on the homepage to create new tasks and projects, and database locking to prevent accidental edits. The result is a single-page task manager that behaves like software—complete with inbox capture, scheduling, project execution pages, recurring logic, subtasks, and a daily journal—while remaining customizable for individual workflows and future upgrades like task history, time tracking, and richer project home bases.

Cornell Notes

The build turns Notion into a full task-management app by combining three databases—Tasks, Projects, and Task Journal—with a homepage that links to specialized views. Tasks get a Status and Due date schema, plus Priority, Smart list (“someday”), Description, timestamps, and a one-to-many Relation to Projects. Layout customization pins the most-used fields and uses a Meta labels formula to show overdue and recurring icons across views. The system then creates workflow views (Inbox, Today, Week calendar, Scheduled, No due, By project, All, Done) and project dashboards using a project page template with self-referential filters. Advanced features add recurring tasks (Next due formula + optional automation) and subtasks (with cautions about relation/filter pitfalls).

Why does the build start with three databases instead of one, and what does each database do?

It creates (1) a Tasks database to store every actionable item, (2) a Projects database to group and track work containers, and (3) a Task Journal database to capture daily planning. The Tasks database holds due dates, status, priority, and a Relation to Projects. The Projects database holds project-level status (planned/doing/ongoing/done), archived state, and a Progress formula. The Journal database supports daily “brain dump” entries, including a template that auto-fills the date when a new journal page is created.

How does the system ensure tasks flow out of the Inbox automatically?

The Inbox view uses Advanced filters with three rules: (1) Status is not complete, so checking a task off removes it; (2) Project is empty, so assigning a task to a project removes it; and (3) Smart list is empty, so tasks moved into “someday” also leave the Inbox. Sorting by Due date (ascending) keeps the Inbox actionable without needing manual cleanup.

What is the Meta labels formula for, and why is it placed in helper properties?

Meta labels is a formula property that outputs icons (via emoji) based on task conditions. It’s built to show overdue status (using a comparison between today and the Due date) and recurring status (using whether Next due is not empty). Putting it in helper properties and then hiding it by default keeps task pages clean, while still allowing list and table views to display the icons consistently across the system.

How do project pages automatically show the right tasks without manual filtering each time?

A project page template creates embedded list/board/calendar views of the Tasks database filtered by a self-referential condition: “project contains project.” When the template is applied to a specific project page, the filter updates itself to reference that project page automatically. This is what makes each project behave like its own mini dashboard with tasks scoped to that project.

How are recurring tasks implemented, and what does the automation change on paid plans?

Recurring tasks use recur interval (number) and recur unit (days/weeks/months/years) plus a Next due formula that adds the interval to the current Due date using dateAdd. On paid plans, an automation triggers when Status becomes Done and then sets Status back to To-do and updates Due date to the Next due value (using the automation formula to reference the triggering page’s Next due). Without automations, the dedicated recurring-tasks view supports manual processing by updating Due date to Next due.

What pitfall can break subtasks inside this setup, and how does the build recommend avoiding it?

Subtasks may not inherit the parent task’s Project relation. That means filtered project views (which show tasks where Project contains a specific project) can fail to display subtasks created under a parent task in another context. The build recommends configuring subtasks display carefully—e.g., in inbox-style views show parents only, and in date-based views use flattened list—so subtasks don’t get “lost” due to mismatched filters and relation inheritance.

Review Questions

  1. If a task is checked off but still appears in the Inbox, which Inbox filter rule is most likely misconfigured (Status, Project empty, or Smart list empty)?
  2. What does the project page template’s self-referential filter accomplish, and what would happen if it pointed to the template rather than the applied project page?
  3. In the recurring-task system, which property is used to compute the next due date, and how is it calculated from Due date plus recur interval/unit?

Key Points

  1. 1

    Build the system around three databases (Tasks, Projects, Task Journal) and connect them with a one-to-many Relation from Projects to Tasks.

  2. 2

    Use a task-friendly Status schema with defaults so new tasks never start with empty status values.

  3. 3

    Create workflow views (Inbox, Today, Week, Scheduled, No due, By project, All, Done) by duplicating a source view and changing filters/sorts rather than rebuilding from scratch.

  4. 4

    Pin frequently edited properties on task pages and use a Meta labels formula to surface overdue/recurring cues across all list views.

  5. 5

    Turn each project into a mini dashboard using a project page template with a self-referential filter so embedded task views always stay scoped to the correct project.

  6. 6

    Implement recurring tasks with recur interval/unit plus a Next due formula; optionally use automations to advance Due date and reset Status when tasks are completed.

  7. 7

    Enable subtasks with care: subtasks may not inherit Project relations, so view filters must be configured to prevent “missing” subtasks in project dashboards.

Highlights

The Inbox view is designed to self-clear using three Advanced filter rules: not complete, Project empty, and Smart list empty.
Project execution pages are automated via a project template that uses a self-referential filter (“project contains project”), so embedded task views always target the applied project page.
Recurring tasks rely on a Next due formula built from dateAdd(recur interval, recur unit) applied to the current Due date, enabling both automation and manual processing.
Meta labels turns task state into at-a-glance icons by combining overdue logic (today vs Due date) and recurring logic (Next due not empty).
Subtasks can silently disappear from project views because subtasks don’t automatically inherit the parent’s Project relation—view configuration is essential.

Topics

Mentioned