Notion's database features have a reputation problem. Relations, rollups and formulas sound like something you'd need a course to understand, so most people stick to a plain table and never touch them. That's a shame, because all three solve genuinely irritating problems. The trick is knowing which one to reach for, and when to leave the whole lot alone. What follows is the version I wish someone had given me: no theory, just examples you can copy into a database you already have open.
Relations: one database pointing at another
A relation is a link between two databases. That's the whole idea. Instead of typing "Website redesign" into a text field on every task, you store it once as a page in a Projects database and point at it from your Tasks database.
The setup is short. Open your Tasks database, add a new property, choose Relation, and select the Projects database. Every task now has a slot for one project, or several if you allow multiple. Notion quietly creates the other half of the link for you: on a project page, a related list of its tasks appears. You don't build that side manually.
When a relation earns its place
- You're typing the same client, project or course name into dozens of rows.
- You keep flicking between two tables to check whether one thing matches another.
- The thing you're linking to deserves its own page, with its own notes and properties.
If it's just a label, use a select property instead. A relation is worth it when the other item is a real thing you'd want to open, filter and group by.
Rollups: counting and adding up across a relation
A rollup can't work without a relation, which is why the two are usually taught together. Once tasks are linked to a project, a rollup reaches into those tasks, reads one property, and produces a single number or value on the project.
- In the Projects database, add a property and choose Rollup.
- Set the relation to Tasks.
- Choose the property to read, such as Estimate or Status.
- Pick the calculation: Sum, Count all, Average, Percent checked, and so on.
A useful pairing: give each task a number property called Estimate, then roll up the sum onto the project. Now you can see that a project is twenty-two hours of work before you agree to it. Another: add a checkbox called Done on each task, roll up Percent checked, and you have a completion figure that updates itself every time you tick something off.
One quirk worth knowing. If a rollup insists on showing "No rollup data" when you're sure the rows are linked, reopen the rollup settings and re-select the relation property and the property to roll up. It's a stale configuration issue rather than anything you've done wrong.
Formulas: doing the arithmetic yourself
A formula works on properties within the same row. It can't see other pages directly — that's the rollup's job. Add a property, choose Formula, and you get a small expression box.
Say each task has a date property called Due. A formula can turn that into something you read at a glance:
dateBetween(now(), prop("Due"), "days")
That returns the number of days left. It comes out negative once the deadline has passed, which is exactly what you want. Wrap it in a condition and the number becomes a word:
if(prop("Days left") < 0, "Overdue", "On track")
Once you're comfortable, formulas get more useful when paired with a rollup. A project with a "Tasks done" rollup and a "Total tasks" rollup can produce a percentage, and then a short sentence: the count of finished tasks, the word "of", the total, and "done". Keep the goal modest. Three clever formulas you understand beat ten you copied and can't debug.
Two practical notes. Formula typos break the whole property, and Notion will flag the offending line rather than guessing what you meant, so build expressions up in pieces. And now() refreshes when a page loads, not every second, so don't treat it as a live clock.
How the three fit together
A freelance designer's setup makes the chain obvious. Tasks carry a Due date, a Status and an Estimate. Projects have a relation to Tasks. On top of that relation sit two rollups: total estimated hours, and percent of tasks checked off. A formula then combines them into a single line on the project page — something like "6 of 11 done, 34 hours remaining". Nobody types any of it. It's all read from the tasks below.
That's the pattern to aim for: relation to connect, rollup to summarise, formula to translate the summary into something a human wants to read. Each layer only makes sense because of the one before it.
When to leave all three alone
Restraint saves more time than automation. Skip the complexity when:
- One of the databases has fewer than about ten rows. A select property does the same job with none of the wiring.
- You're stacking rollups three levels deep, such as a rollup reading a rollup reading a rollup. It gets slow, and a single broken link breaks the lot.
- The formula needs a comment to explain it and you're the only person who'll ever read that comment.
- You're building it for a hypothetical future project rather than the one in front of you.
A build order that holds up
Start with one database and a handful of properties. Add a relation the first time you catch yourself typing the same name into five rows. Add a rollup the first time you count something by hand. Add a formula the first time you do the same small calculation twice in a week.
Test each addition on two or three rows before you commit, and keep property names short, because they'll appear inside every formula you write later. If a feature isn't saving you a step, delete it. A database you actually maintain beats an impressive one you quietly abandon.
Photo: danieltibi / Pixabay