Notion Office Hours: Relations & Rollups 🎩

TL;DR

Use relation properties to connect records across databases so parent pages can reliably filter and display their related children.

Briefing Cornell Notes

Briefing

Relations and roll-ups in Notion are the core mechanism for turning separate databases into a connected system—so categories can automatically organize items, and summary metrics (totals, dates, completion rates) can update without manual re-entry. The practical payoff is consistency and speed: once relationships are set, changes propagate across every view that depends on them, and dashboards can be built from linked, filtered slices of the same underlying data.

The session starts with the “relation” property: a way to connect items in one database to items in another. A worked example uses expense categories as the parent and individual expenses as the children. Instead of using a simple select field for categories, a relation property links each expense to a category record in the categories database. Because Notion supports reciprocal relationships, creating the relation automatically adds a corresponding relation field back on the other database—so each category can list all linked expenses. The same parent-child pattern is extended beyond finance: projects can connect to tasks, and recipes can connect to ingredients. In some cases the relationship is effectively bidirectional (ingredients ↔ recipes), enabling filtering in either direction.

The most important functional leap comes from combining relations with linked database views and templates. By adding a linked database inside a category page and filtering it to show only items related to that category, the workspace can display “just the children” for the current parent. To avoid rebuilding this for every new category, the session demonstrates a self-referencing filter inside a database template: when a new category is created from the template, the embedded linked view automatically filters to the newly created category. As a result, adding a new expense from within the category’s filtered view automatically populates the relation field—so the system stays wired together.

Roll-ups then take the next step: they pull values from all related child records back into the parent. A roll-up on categories calculates total cost by summing the “cost” property from linked expenses. The same roll-up framework can summarize dates (earliest, latest, or date range), and it can compute progress using checkboxes—such as the percent of tasks marked complete. A key workaround is also highlighted: when roll-ups’ built-in “sum” formatting can’t be displayed as currency, a formula property can reference the roll-up result so the final value can be formatted properly.

The session moves into more advanced structures to show why relations matter at scale. Vendors are introduced as an additional database that sits between expenses and categories: expenses relate to vendors, vendors relate to categories, and roll-ups can infer the category for each expense via the vendor link. That enables roll-up-based summaries by category and vendor without duplicating categorization work. Time-based roll-ups are layered in using a months database, allowing averages like “average spending per month.”

Finally, the same pattern is applied to a client/project/task/resource setup: clients connect to projects, projects connect to tasks, and tasks roll up into project-level completion percentages. The session closes with a real-world reflection workflow example—daily journal entries roll up into a weekly agenda/report—showing how relations and roll-ups can power recurring review and reporting without manual aggregation. The overall message is that the upfront modeling work (relations, templates, roll-ups) becomes a reusable infrastructure that keeps data accurate, reduces redundancy, and makes dashboards update automatically.

Cornell Notes

Relations connect records across Notion databases, typically forming a parent-child structure (e.g., categories → expenses, projects → tasks). Templates plus linked database views let each parent page automatically show only its related children, and self-referencing filters ensure new parents come with the correct filtered views. Roll-ups then aggregate child properties back into the parent—summing costs, summarizing dates (earliest/latest/range), and calculating progress from checkboxes as a percent complete. These features reduce redundancy because updates propagate through the relationship graph instead of relying on manual copying or select-field maintenance. The result is a workspace that can generate dashboards and reports (like weekly reviews) from connected data.

How does a relation property change category assignment compared with using a select property?

A relation property links each item in one database to a record in another database. In the expense example, each expense record links to a category record in the categories database. That connection is reciprocal, so the category page can list all linked expenses. The key benefit is that category changes propagate consistently across every place that depends on the relationship, whereas select options require manual upkeep across multiple databases.

What problem do linked database views and templates solve after relations are created?

Linked database views let a parent page display a filtered view of the child database (e.g., the Housing category page shows only expenses mapped to Housing). Templates prevent rebuilding that filtered view for every new parent. With a self-referencing filter in the template, the linked view automatically filters to the newly created parent record, and adding a child item from within that view automatically populates the relation field.

What can roll-ups aggregate, and how is progress calculated?

Roll-ups can pull values from properties on related child records and compute results like sums, date summaries (earliest/latest/range), and checkbox-based metrics. For progress, the session demonstrates a roll-up that calculates the percent of checked items among all related children—useful for tasks within a project. As checkbox states change on tasks, the project-level percent updates automatically.

Why use a formula property alongside a roll-up for currency formatting?

When roll-ups use “sum,” the session notes that currency formatting may not be available directly in the roll-up’s output. A workaround is to create a formula property that references the roll-up’s final value, then apply currency formatting to the formula result. The roll-up can be hidden while the formatted formula displays the correct dollars.

How does the “vendors” example reduce duplicate categorization work?

Instead of linking expenses directly to categories, expenses link to vendors, and vendors link to categories. A roll-up on categories can then infer the category for each expense via the vendor relationship. This avoids manually assigning categories to every expense and keeps categorization consistent because the category mapping lives in one place (the vendor record).

What’s the practical takeaway for building dashboards like a weekly agenda from daily entries?

Daily journal entries can be modeled as child records related to a weekly parent record. Roll-ups then aggregate properties like effectiveness, words used, and tasks from the daily entries into the weekly agenda/report. The weekly view becomes a generated summary rather than a manually compiled document, supporting reflection workflows without extra aggregation steps.

Review Questions

When should a self-referencing filter be used in a template, and what does it automate when creating new parent records?
What roll-up operations are demonstrated for numbers, dates, and checkboxes, and how do they differ in output?
Describe the vendor-based hierarchy and explain how roll-ups can infer categories without direct expense-to-category relations.

Key Points

1
Use relation properties to connect records across databases so parent pages can reliably filter and display their related children.
2
Rely on reciprocal relations to avoid manual back-linking; Notion can populate the reverse relation automatically.
3
Combine linked database views with templates to create per-parent filtered child lists without rebuilding them for every new parent.
4
Apply self-referencing filters in templates so newly created parent records automatically generate correctly filtered linked views.
5
Use roll-ups to aggregate child properties into parent records—sums for totals, date roll-ups for earliest/latest/ranges, and checkbox roll-ups for percent completion.
6
When roll-up currency formatting is limited, reference the roll-up value in a formula property to display properly formatted currency.
7
Model multi-step hierarchies (e.g., expenses → vendors → categories, or clients → projects → tasks) to eliminate redundant manual categorization and keep data consistent.

Highlights

Relations turn classification into a connected system: expenses link to categories, and categories automatically list their expenses through reciprocal fields.

Self-referencing filters inside templates make new parent records “come pre-wired,” so adding children from within a filtered view auto-populates relations.

Roll-ups can function as built-in analytics: sum totals, summarize date ranges, and compute progress as percent checked from related tasks.

A vendor intermediary database can infer categories for expenses via roll-ups, removing duplicate categorization work.

Checkbox roll-ups provide a straightforward progress metric at the project level, updating instantly as task completion changes.

Topics

Notion Relations
Notion Roll-Ups
Database Templates
Parent-Child Modeling
Progress Tracking

Mentioned

William Nutt