Notion Databases for Project Management, Explained
Not a generic Notion database tutorial — this one covers exactly the property types that make project management work, with the specific PM use case for each, not a full feature tour.
This isn’t a full Notion database feature tour — it’s specifically the property types that make project management work: Relation, Rollup, Formula, and Select, with the exact PM use case for each, so you know which one to reach for and why.
Not a full feature tour — just what matters for PM
Notion databases support a long list of property types. For project management specifically, four of them do almost all the real work. Understanding what each one actually does — not just its name — is the difference between a system that holds together and one that quietly breaks, which is the underlying cause of most of the failure modes covered in our main tutorial.
Relation: connecting two databases
A Relation property links a row in one database to one or more rows in another — Tasks to Projects, Projects to Clients. It’s the single most important property type in any multi-database PM structure, because it’s what makes rollups and cross-database views possible at all. A text field that just looks like a relation (typing “Website Redesign” into a plain text box) provides none of this — see the mistakes section below.
Rollup: pulling data across a relation
A Rollup reaches across an existing Relation and aggregates data from the related rows — counting them, summing a number field, or calculating a percentage. The % Complete rollup in our main tutorial (percent of related Tasks with Status = Done) is the clearest example: it only works because a real Relation exists underneath it.
Formula: calculating within a row
A Formula calculates a value using properties already on the same row — including a Rollup’s output. Useful for things like flagging a project red if its Deadline rollup is within 7 days and % Complete is under a threshold. Reach for a Formula only after confirming a Rollup alone can’t answer the question; formulas referencing relation data manually are more fragile than the native Rollup type built for that job.
Select vs. Relation: when to use which
| Select / Multi-select | Relation | |
|---|---|---|
| Use for | Fixed, short option lists (Status, Priority) | Connections to records with their own data (Project, Client, Team member) |
| Supports rollups? | No | Yes |
| Setup speed | Faster | Slightly slower, worth it when data matters |
How to apply this
How to Apply This
- 1
Audit your current properties
For each one, ask: is this a Select pretending to be a Relation?
10 min
- 2
Convert any text/select “relation” fields to real relations
The single highest-impact fix from this guide.
15–30 min
- 3
Add one rollup that answers a real question
“How much is done” or “how many are overdue” — not just because rollups exist.
10 min
- 4
Add a formula only if a rollup genuinely can’t do the job
Most PM needs are covered by relation + rollup alone.
varies
Ready to apply this to a real structure?
See these exact property types in action in our main step-by-step Projects/Tasks/Team tutorial.
Property audit checklist
Property Audit Checklist
- Every “which project does this belong to” field is a true Relation, not a Select or text field
- At least one Rollup exists pulling a real aggregate (count, sum, or percent) across a relation
- Formulas are used sparingly, only where a rollup alone can’t answer the question
- Select properties are reserved for genuinely fixed, short option lists (Status, Priority)
Common mistakes
Common Property Mistakes
- Using a Select or multi-select as a stand-in for a Relation. — Looks identical in a table view for the first few rows, then silently diverges as project names get typed inconsistently — the single most common structural mistake in DIY Notion PM builds.
- Building a formula to do what a rollup already does natively. — Formulas that manually reference relation data are more fragile and harder to debug than the built-in Rollup property type designed for exactly this.
- Turning every property into a Relation, even ones that don’t need it. — A Priority field doesn’t need to be a related database — Select is faster to set up and query for genuinely fixed short lists.
- Not knowing which property type is doing the work when something breaks. — When a rollup shows an unexpected number, the fix is almost always in the rollup’s own filter settings — not the relation, and not a formula elsewhere.
Free Notion Template
Projects + Tasks Starter Kit
Every property type from this guide, correctly configured and ready to duplicate.
Template link placeholder — replace href with the live Notion “Duplicate” share link before publishing.
FAQ
What’s the difference between a rollup and a formula?
A rollup pulls and aggregates data from a related database (e.g., summing Story Points from related Tasks). A formula calculates using properties on the same row — they can also reference a rollup’s output, but a formula alone can’t reach across a relation the way a rollup does.
When should I use a Select property vs. a Relation?
Select for a fixed, short list of options that don’t need their own additional data (Status: To Do/In Progress/Done). Relation when the option is itself a real record with its own properties — a Project, a Client, a Team member.
Do I need the Notion API to make any of this work?
No — relations, rollups, and formulas are all native database features, no API or code required. The API becomes relevant only for automations beyond what Notion’s built-in Automations button covers.
Is there a limit to how many relations one database can have?
No hard practical limit for typical project management use — a Tasks database relating to Projects, Team, and a self-relation for sub-items simultaneously is common and works fine.
We turn workflows like this into a working Notion system in days, not months.
Find Your Solution