Notion Database Relations & Rollups + System Updates

TL;DR

Create a “Relation” property to link records between two databases, then add a “Roll-up” to pull specific fields from the linked records into the referencing database.

Briefing Cornell Notes

Briefing

Notion roll-ups are the mechanism that turns a web of database relations into an automatically populated “life OS,” letting key fields (dates, statuses, notes, counts, and even calculated metrics) flow across systems without re-entering them. The core workflow is simple: create a relation between two databases, then use a roll-up to pull specific properties from the related records into the referencing database—so when new items get linked, the derived fields update automatically.

The walkthrough starts from scratch with a demo table. A new database property is set to “Relation,” linking each row (an entry/record) to a specific record in another database (for example, connecting “sample” items to tasks in an action-items database). Once those links exist, the roll-up becomes the extension: a roll-up property is configured to reference the relation and then select which fields from the connected database should appear—such as due dates, statuses, or a “content item” connection that only exists for some tasks. The presenter emphasizes that roll-ups depend on relations, and that roll-ups are often treated as “advanced,” but the setup is mostly choosing (1) which related database to pull from and (2) which property to bring in.

From there, the system’s practical value shows up in the alignment zone and action zone. Content items connected to tasks automatically inherit next-action dates and statuses via roll-ups, so a single task view can display the editing schedule for multiple videos without manual duplication. The same pattern is used in the opposite direction: opening a content item shows the task’s due date roll-up, helping keep editing and next actions aligned across databases.

Several system updates refine the data model. Goal outcomes are converted from a direct relation into a roll-up through projects, reducing manual steps because projects already connect to goal outcomes. A “pillars” connection is removed from the action-items database because roll-ups can’t be stacked (“roll-up of a roll-up”), and the hierarchy already preserves the pillars link through projects → goals → pillars. In the projects database, value goals are added as a roll-up from goal outcomes, and pillars are pulled in as a roll-up from value goals—ensuring consistency and eliminating repeated entry.

The most powerful examples go beyond copying fields. Roll-ups aggregate across many related records and can apply math. In monthly reviews, weekly items are attached to a month, and roll-ups populate most fields automatically—learnings, accomplishments, disappointments, and effectiveness ratings—so end-of-month review work becomes mostly filling in themes and gratitude. Weekly tracking uses roll-ups over daily data to compute metrics like the percent of workout days checked, average sleep hours, and ranges via “show original” views. Because roll-up-of-roll-up isn’t supported, daily roll-up results are summarized at the week level before rolling into the month.

Finally, roll-ups support operational dashboards. A new “actions remaining” column counts unchecked tasks (using the done checkbox) per project, avoiding clutter from mixing completed and incomplete items. Similar counts are added for goal outcomes: how many projects are queued and active to advance each goal outcome, using an “active” checkbox because roll-ups work more reliably with booleans than with single-select statuses. The net effect is faster setup, fewer manual updates, and higher accuracy because shared facts propagate through relations rather than being maintained in parallel.

Cornell Notes

Roll-ups in Notion turn database relations into automatic, cross-database fields. After linking two databases with a “Relation” property, a “Roll-up” pulls chosen properties (like due dates, statuses, or linked content items) from the related records into the referencing database. The system uses roll-ups to keep action planning and alignment consistent: tasks can display next-action dates for multiple content items, and content items can inherit task due dates. More advanced roll-ups aggregate many related records and can compute metrics such as percentages and averages. The model also avoids “roll-up of a roll-up” limitations by summarizing at the week level before rolling into months and years.

How does a roll-up differ from a relation, and what are the two key choices during setup?

A relation creates the link between records in two databases (each row can point to one or many records in the other database). A roll-up then uses that relation to pull specific data from the linked records into the current database. Setup boils down to: (1) selecting which relation/database to pull from (e.g., the action items database), and (2) selecting which property from that related database to bring in (e.g., due date, status, or a connected content item).

Why does the system convert some direct relations into roll-ups (like goal outcomes), and what problem does it solve?

Direct relations require extra manual maintenance. When tasks already connect to projects, and projects already connect to goal outcomes, converting the goal outcome field into a roll-up lets it populate automatically through the existing project link. That removes an extra step and keeps the data synchronized as new tasks/projects are added.

What limitation affects roll-up design, and how does the system work around it?

Notion doesn’t support “roll-up of a roll-up.” That means results produced by a roll-up can’t be rolled again into another database field. The system works around this by summarizing at an intermediate level: daily roll-up outputs are summarized into a weekly interpretation, and only then roll that summary into monthly and yearly views.

How are roll-ups used to compute metrics rather than just display copied fields?

When the roll-up targets numeric or boolean-like data across many related records, it can apply formulas. For example, workout completion is computed as the percent of days in a week where a workout checkbox is checked. Sleep metrics use averages (e.g., average sleep hours) and can show original values to reveal ranges and outliers. Daily “wine down” completion is rolled up as an average success rate for the week.

How does the “actions remaining” column avoid clutter while still staying accurate?

Instead of relying on a view that mixes completed and uncompleted tasks, the system uses a roll-up count based on the done checkbox. For each project, it counts tasks linked to that project whose done box is unchecked. This gives a clean “remaining” number in the project view while keeping the underlying task links intact.

Why remove the pillars connection from the action-items database?

Pillars are still important, but adding a pillar to every action item is too cumbersome. The hierarchy already preserves the pillar link through projects and goals. Keeping pillars only at the appropriate downstream level also avoids roll-up stacking issues, since the system can pull pillars consistently via relations and roll-ups without requiring direct pillar entry on every task.

Review Questions

When would you choose a relation-only setup versus adding a roll-up, and what specific property would you pull first?
Where does the system rely on roll-ups for aggregation and math (percent/average), and what data type makes that possible?
How does the system structure summaries to handle the “roll-up of a roll-up” limitation without losing important detail?

Key Points

1
Create a “Relation” property to link records between two databases, then add a “Roll-up” to pull specific fields from the linked records into the referencing database.
2
Use roll-ups to propagate planning data like due dates and statuses across views so alignment stays consistent without manual re-entry.
3
Convert direct relations to roll-ups when an intermediate database already connects the same entities, reducing redundant maintenance steps.
4
Avoid “roll-up of a roll-up” by summarizing at an intermediate level (e.g., daily → weekly) before rolling into higher-level views (e.g., monthly/yearly).
5
Use roll-ups for aggregation and calculations—such as percent of checkbox-checked days, averages, and ranges—to turn raw daily logs into decision-ready metrics.
6
Count remaining work with roll-ups over boolean checkboxes (like done) to prevent completed items from cluttering operational dashboards.
7
Represent “active” progress with checkboxes when roll-ups work better with booleans than with single-select status fields.

Highlights

Roll-ups are configured by choosing the related database via the relation, then selecting which property to pull—turning linked records into automatically populated fields.

The system keeps action planning aligned by rolling due dates and statuses across content items and tasks in both directions.

Monthly and yearly reviews become mostly automatic because weekly items are attached to months, and roll-ups aggregate learnings and ratings across those links.

Roll-ups can calculate metrics like “percent of workout days checked” from daily checkbox data, not just display text fields.

Operational clarity improves when “actions remaining” counts unchecked tasks via roll-ups, avoiding clutter from mixing completed and incomplete records.

Topics

Mentioned

August Bradley
Anton Milano