Implementing a Linked Notion Database with Relation and Rollup Properties

Implementing a Linked Notion Database with Relation and Rollup Properties

Desired Outcome

The goal is to create a primary database that references a secondary database through a Relation property, and use a Rollup property to pull aggregated data from the linked records, giving a single source of truth and consistent filtered views.

Prerequisites

• Workspace edit access for the user who will modify the databases.
• Two existing databases with stable, unchanging property names (e.g., Tasks and Projects).
• A clear data model defining the cardinality (one‑to‑many or many‑to‑many) between the entities.
• Agreement on who may edit relations and rollups to avoid accidental changes.

Procedure

1. Add the Relation property to the primary database (e.g., Tasks). In the property menu choose “Relation”, then select the secondary database (Projects) as the target. Set the cardinality: many‑to‑one if each task belongs to a single project, or many‑to‑many if a task can link to multiple projects.
2. Add the reciprocal Relation property to the secondary database (Projects). Choose the primary database (Tasks) as the target and use the same cardinality setting.
3. Create a Rollup property in the primary database. In the property menu select “Rollup”, pick the Relation property you just created, and choose the source property from the secondary database that you want to aggregate (for example, the Status select or Due date date). Set the aggregation function (e.g., “Show original” or “Count”).
4. Build filtered views for each linked set. In the primary database, click “+ Add a view”, select “Table”, then click “Filter” and add a condition that uses the Relation property (e.g., “Project” is not empty). Name the view “Tasks by Project”.
5. Optionally apply a database template to standardize new entries. Click the three‑dot menu on the database, choose “Templates”, then “Create new template”. Include the Relation property pre‑filled if desired.

Concrete Example

Imagine a Tasks database that tracks work items and a Projects database that stores project details. In Tasks add a Relation property called Project linking to Projects. In Projects add a Relation property called Tasks linking back. Set the cardinality to many‑to‑one (each task belongs to one project). Add a Rollup property in Tasks named Project Status that rolls up the Status select property from Projects. Now a task row shows the project’s current status without manual entry.

Verification Checks

• Open a record in Tasks and confirm that the linked Projects record appears in the Project relation field, and that the reciprocal Tasks relation field on the project page lists the task.
• Change the Status value on a Projects record and verify that the Project Status rollup in the related Tasks record updates instantly.
• Create a new entry using the database template and ensure the Relation and Rollup properties are populated automatically.
• Log in with a read‑only account to confirm that the database can be viewed but not edited, protecting the intended permission boundaries.

Recovery Options

• Duplicate the primary and secondary databases before making schema changes; the duplicate serves as a rollback point.
• Use page history to restore a deleted or altered relation on a specific page (click the three‑dot menu on the page, choose “History”).
• If a relation property behaves unexpectedly, delete the property from both databases and recreate it with the correct target and cardinality.
• Maintain an export backup (CSV or JSON) of critical databases; import the file after a failed schema change to restore data.

Version‑Specific Notes

UI labels for “Add a property” and the exact location of the Relation type can differ between the web client and desktop apps, especially in older Notion versions. Always verify the steps on the client you will use, and test the relation bidirectional flow after any UI update.