Notion Databases: Relations, Rollups & Views, From Scratch

A Notion database is where the app stops being a notebook and starts being software. This guide builds one from scratch and covers the three ideas that separate a toy database from a working one: relations, rollups, and views.

Step 1: Create the database

Type /table on any page and choose Table - Full page. You now have a database with a single default Name property. Every row can open into its own page, which is where the long-form detail lives.

Step 2: Add the right properties

Properties are the columns. Choose types deliberately:

• Text for free notes.
• Select for fixed categories (use this over Text when you can, so you can filter).
• Multi-select for tags.
• Date for deadlines and timelines.
• Person for ownership.
• Checkbox for done/not-done.
• Number for money, counts, scores.
• Formula for anything computed from other properties.

Keep the property count low

Every property is a maintenance cost. Start with five. Add more only when a real workflow demands it.

Step 3: Relate databases with relations

A relation connects two databases. In a CRM, relate a Clients database to a Projects database so each client opens to its projects. This is how you model a real business instead of copying names between tables.

Self-relations

A database can relate to itself. Use this for task dependencies (a task blocks another task) or parent-child records.

Step 4: Aggregate with rollups

A rollup pulls a number from a related database. In the Clients database, roll up the sum of each client's project budgets. Rollups turn related rows into a single answer on the parent, which is what dashboards need.

Step 5: Choose your views

A view is a saved lens on the same underlying data. The data is single; the views are many.

• Table for editing and data entry.
• Board for status workflows (To Do, Doing, Done).
• Timeline and Calendar for date-based planning.
• Gallery for visual items (designs, covers).
• List for compact reading.

Filter and sort every view

A view without a filter is just the whole database again. Always set a default filter and sort so the view answers a specific question on open.

A worked CRM example

Create a Clients database with Select status, Person owner, and Number revenue. Create a Projects database with a relation to Clients, Date deadline, and Select status. On Clients, add a rollup counting open projects and a rollup summing project revenue. Add a Board view grouped by status to both. You now have a CRM where changing a project status updates the client dashboard automatically.

Common mistakes

• Duplicating data instead of relating it. If a client name appears in two databases as text, you have a relation waiting to happen.
• Too many views. Six views no one filters is noise. Keep the views you actually open.
• Using Text where Select would do. You lose filtering and invite typos.

Skip the build

The store ships pre-related databases (CRM, content calendar, project tracker) so the relations and rollups are already wired. Duplicate and start entering data.