One Source of Truth: Using Notion Linked Databases Without Losing Your Mind

If you've ever copied a project tracker onto a team page, then onto a personal dashboard, then onto a meeting notes page, you already know the failure mode: three versions of the same list, each slightly stale, and nobody sure which one is right. Notion's Linked Databases feature exists specifically to kill that problem, and it's one of the most underused parts of the product.

The core idea is simple. Instead of duplicating a database, you embed a live view of the original anywhere else in your workspace. The data stays in one place; the views multiply. Change a row in the source, and every embedded view reflects it immediately.

What a linked view actually is

A linked database view is a window into an existing database, not a copy. You can place that window on any page and then customize how the data is presented: apply filters, change the sort order, hide or show properties, and switch between table, board, calendar, or gallery layouts. None of those changes touch the source database or anyone else's views of it.

This separation between data and presentation is the whole point. One team can look at a board grouped by status while another looks at a table filtered to their department, both reading from the same rows.

Setting one up

The mechanics take about a minute:

1. Open the page where you want the view to live.
2. Type /linked and choose Linked view of database (in older versions, the block is called Create linked database).
3. Search for and select your source database.
4. Use the filter, sort, and property toggles in the view's toolbar to shape what this particular window shows.

A quick sanity check: edit a row in the source database and confirm the change appears in the linked view within a second or two. If it does, your link is live and working as expected.

A worked example: one tasks database, three audiences

Say you have a master Tasks database with properties for Owner, Status, Due Date, and Team. Instead of exporting slices of it, you create three linked views:

• On the engineering team page: a board view filtered to Team = Engineering, grouped by Status.
• On your personal dashboard: a table filtered to Owner = you and Status ≠ Done, sorted by Due Date ascending.
• On the weekly planning page: a calendar view filtered to tasks due in the current week.

When someone marks a task complete in any context where editing is possible, or in the source database directly, all three views update. There's nothing to sync manually and no drift between copies, because there are no copies.

The trade-offs worth knowing

Linked views are not a free lunch, and two limitations come up constantly in practice.

Editing can be confusing. Historically, linked views were read-only, and even where inline editing is now possible, permissions follow the source database. A teammate who can see a linked view but lacks edit rights on the source won't be able to change anything, which trips up new users. The fix is expectation-setting: treat linked views as dashboards, and make it clear where the canonical editing happens.

Performance degrades at scale. If your source database has thousands of rows and a single page embeds several linked views, page load can get sluggish. Practical mitigations: filter aggressively so each view renders fewer rows, hide properties you don't need, and resist the urge to stack five views of the same giant database on one page.

There's also a subtler risk: because filters are per-view, two people can look at “the tasks list” and see different things. Naming your views descriptively (“Open Engineering Tasks”, not “Tasks”) prevents most of that confusion.

Where to go from here

Start small: pick the one database in your workspace that has been copy-pasted the most, replace the duplicates with linked views, and give each view a name that states its filter. Then verify the behavior yourself — edit a row in the source and watch every linked view update. Once that clicks, the natural next step is combining linked views with database templates and relations, which is where Notion starts to feel less like a wiki and more like a lightweight internal tool.